Memoire Online - Plateformes de services intégrés pour mobiles

· A mon défunt Père : Papa ce mémoire est pour toi, tu m'as forgé et tu as cru en moi mais tu es parti sans voir un de tes rêves se réaliser. Je ne te remercierai jamais assez. Que la terre te soit légère.

· A ma mère, ma complice : ce mémoire est le fruit de ta générosité, de ton soutien et de la confiance que tu a toujours portée en moi. Que Dieu te bénisse et t'accorde longue vie.

· A Babacar, mon frère et professeur, à Pape, à Laye, à mes grandes soeurs Oumy, Ami, Séné, Khady et à leur mère pour toutes les années harmonieuses vécues ensemble.

· A Makhtar et à Seynabou, petit frère et petite soeur : vous êtes uniques pour moi, je vous adore.

· A toute ma famille : oncles, tantes, cousins, cousines. Mention spéciale à mon oncle Babacar Loum.

· A mes amis qui se reconnaîtront ; parmi eux je citerai Mourath Ndiaye, Pape Matar Faye et Médoune Diaw.

· A mes camarades-ingénieurs : Niane mon voiz, Saliou mon partenaire de stage, Omgue mon grand ami, Sow le maat-maticien, Amar, Issa Baldé, Diaw, Khalifa, Wade, Mbacké, Souleymane, Bamba..., et à toutes les filles de la promo.

· Monsieur Samuel Ouya, mon professeur encadreur, pour son soutien, sa disponibilité et ses conseils,

· Monsieur Ahmat Bamba Mbacké, pour sa disponibilité, sa relecture, ses corrections et ses conseils,

· Tous les professeurs qui nous ont encadrés pendant ces trois ans : si nous sommes de bons informaticiens c'est grâce à vous,

· Messieurs Omar Cissé, Mamadou Faye, Djibril Mané, Maximilien Diouf, Ousmane Cissé pour m'avoir accueilli et bien intégré dans leur structure : 2SI,

· Messieurs Djibril Mané (Maître de stage) et Mamadou Faye (directeur technique toujours disponible), pour leur rigueur et leurs conseils,

· Toute l'équipe de développement : Saliou, Mbodj, Dem, Rougui, Omar, Jean, Morel, Doumboua, Maniang, Martin, Malick, Adama, Coura, Arame, etc.

· Tous ceux qui ont participé de près ou de loin à la rédaction de ce mémoire.

2.1 Front-office, back-office, paiement...........................................115

2.2 Portail USSD..................................................................115

2.3 Génération et validation du ticket..........................................115

Glossaire .............................................................................................................................................130

API	Application Programming Interface
CDC	Connected Device Configuration
CLDC	Connected Limited Device Configuration
CU	Cas d'Utilisation
DTD	Document Type Definition
GPRS	General Packet Radio Service
GSM	Global System for Mobile communication
GUID	Global Unique Identifier - identifiant global unique
HTTP	HyperText Transfer Protocol
IDE	Integrated Developement Environment
IMEI	International Mobile Equipment Identifier
IP	Internet Protocol
J2EE	Java 2 Entreprise Entreprise Edition
J2ME	Java 2 Micro Edition
J2SE	Java 2 Standard Edition
LUID	Local Unique Identifier - identifiant local unique
MIDP	Mobile Information Device Profile
MMS	Multimedia Message System
MMSC	Multimedia Message System Center
OBEX	OBject EXchange
OS	Operating System
PIM	Personnal Information Manager
QoS	Quality of Service
SI	Système d'Information
SMS	Short Message System
SVA	Service à Valeur Ajoutée
UML	Unified Modeling Langage
UP	Unified Process
USSD	Unstructured Supplementary Service Data
WAP	Wireless Application rotocol
WSP	Wireless Session Protocol
WTK	Wireless ToolKit
XML	eXtensible Markup Language
XP	eXtreme Programming

Pour l'obtention du Diplôme d'Ingénieur de Conception (DIC), les étudiants du département informatique de l'ESP doivent effectuer un stage de cinq (5) mois pour mettre en pratique leurs connaissances théoriques acquises pendant (3) ans.

C'est dans ce dessein que nous avons intégré la société 2SI, structure dans laquelle nous avions charge de mener un projet informatique dont la teneur est consignée dans ce mémoire.

Ce mémoire présente deux nouveaux services, au Sénégal, dans l'environnement du téléphone portable, devenu le terminal majeur de communication dans ce pays et dans le monde.

Le boom de l'utilisation de cet appareil, combiné à la précarité de sa durée de vie et à l'importance des données qu'il transporte, pose le problème de l'intégrité de celles-ci.

Sa portabilité pourrait aussi être utilisée à des fins autres que la communication téléphonique uniquement.

Dans ce contexte, 2SI propose de concevoir une plateforme à même de valoriser ce terminal mobile au grand bénéfice des propriétaires. Cette plateforme sera constituée de deux types de services :

· Un service de sauvegarde à distance du répertoire des contacts des abonnés

· Un service de billetterie dématérialisée dans lequel le téléphone jouera le rôle de porte billet électronique.

Introduction

Les progrès technologiques récents ont permis l'apparition d'une grande variété de nouveaux moyens permettant à un utilisateur d'accéder et d'utiliser l'information qui l'intéresse en tout lieu couvert par le réseau et à tout moment. L'accès au contenu ne s'effectue plus exclusivement de la même façon ni par les mêmes appareils qu'il y a quelques années. Ces nouveaux appareils, fruits d'une véritable révolution technologique, ont pour nom : assistants personnels, téléphones cellulaires, smartphones, etc. Le nombre d'utilisateurs de ces nouveaux appareils continue sa croissance exponentielle. Les moyens d'accès au contenu ont également évolué, avec de nouveaux réseaux tels que les réseaux sans fil WiFi, GPRS, UMTS, etc. Ces réseaux se sont développés et se sont intégrés à l'Internet. L'utilisation du World Wide Web ne ressemble donc plus à ce qu'elle était à l'origine, où l'utilisateur accédait à l'information depuis son ordinateur personnel et à travers le réseau filaire.

Le concept de terminal mobile est ainsi né. Par définition c'est un appareil qui peut être déplacé ; par principe c'est un appareil de taille réduite. Cette taille n'est pas seulement le produit des avancées technologiques mais elle est tributaire de la puissance, du reste, limitée des terminaux mobiles. L'embarqué et la mobilité dont les besoins sont aussi divers que variés : allant de la carte à puce au satellite en passant par la téléphonie mobile ou le radar automatique, vont être de plus en plus présents dans notre quotidien du fait de l'explosion du marché des machines mobiles et de leurs applications.

Conscient de l'utilité et de l'ampleur de plus en plus grandissantes de ces appareils, 2SI concepteur d'innovations, propose aux opérateurs de téléphonie une plateforme de services qui permettra aux mobiles de remplir leur rôle dans la mise en place d'une société de l'information compétitive et dynamique, au grand bénéfice des utilisateurs. Cette solution vise à tirer le maximum de profit de la convergence des technologies et des concepts vers un seul appareil multimédia.

Ce mémoire s'articulera autour de trois parties : une première dans laquelle nous présenterons notre structure d'accueil et camperons notre sujet, une deuxième qui traitera de l'analyse et de la conception de la plateforme à réaliser et une troisième qui sera consacrée à l'implémentation et à la présentation de la solution.

Première partie : Présentation générale et choix d'une méthode d'analyse

Ø La présentation de la structure d'accueil et du sujet : nous présenterons de manière succincte l'entreprise " Stratégies et Solutions Informatiques (2SI)" et le sujet que nous avons traité en posant sa problématique et ses objectifs.

Ø Choix d'une méthode d'analyse et de conception : Pour mettre en oeuvre la solution proposée, nous ferons à travers ce chapitre la présentation de méthodes d'analyse et de conception puis un choix de l'une d'entre elles.

Chapitre 1 : Présentation générale

Implantée depuis l'année 2001 par un groupe d'ingénieurs informaticiens sortis de l'Ecole supérieure Polytechnique de Dakar, 2SI est leader dans la prestation de solutions et de services innovants dans le domaine des technologies de l'information et de la communication destinés aux entreprises, aux organisations et aux administrations.
Elle est composée d'une dizaine d'ingénieurs de conception, d'un réseau de partenaires au Sénégal et à travers le monde (France, USA, Chine, ...) et offre à sa clientèle un ensemble de solutions métiers, afin d'augmenter la productivité, de faciliter la prise de décision et de mettre à niveau les compétences en entreprise.

Les domaines d'activités de la société sont divers. 2SI intervient en effet dans :

Les téléphones mobiles d'aujourd'hui sont allés au-delà de leur rôle primitif d'outils de communication et ont progressé pour devenir une extension de la personnalité de l'utilisateur. Nous assistons à une époque où ces derniers n'achètent plus ces appareils afin d'être seulement en contact avec d'autres personnes, mais d'exprimer eux-mêmes, leurs attitudes, sentiments, et intérêts.

Les clients veulent continuellement plus de leur téléphone. Ils les utilisent pour stocker leurs données, jouer, lire des articles de presse, surfer sur Internet, avoir un aperçu sur l'astrologie, écouter de la musique, consulter leur solde bancaire, etc.

Ainsi, il existe un vaste monde au-delà de la voix qui doit être exploré et exploité et toute l'industrie cellulaire se dirige vers celui-ci pour fournir des options novatrices à ses clients. Les abonnés ayant l'embarras du choix, ils commencent à choisir leurs opérateurs sur la base des services à valeur ajoutée qu'ils offrent. L'importance accrue de SVA a également incité les développeurs d'applications à proposer de nouveaux services et concepts.

Dans ce sens, un boom de SVA basés sur les SMS a été constaté un peu partout dans le monde, au Sénégal en particulier, laissant en rade d'autres technologies aussi avantageuses disponibles dans les réseaux actuels de téléphonie mobile, et répondant globalement aux attentes des abonnés.

Notre plateforme de services intégrés vise à atteindre les objectifs suivants :

· Participer à la rentabilisation des investissements des opérateurs pour la mise en place, de réseaux téléphoniques évolués en utilisant les possibilités de ressources de ces réseaux,

· Participer à la rentabilisation des investissements des abonnés pour l'acquisition de terminaux onéreux multifonctionnels,

· Etre un allié sûr des propriétaires de terminaux dans la sauvegarde de leurs données personnelles,

Chapitre 2 : Choix d'une méthode d'analyse et de conception

Un projet informatique, quelle que soit sa taille et la portée de ses objectifs, nécessite la mise en place d'un planning organisationnel tout au long de son cycle de vie. C'est ainsi qu'est apparue la notion de méthode.

Une méthode, dans le contexte informatique, peut être définie comme une démarche fournissant une méthodologie et des notations standards qui aident à concevoir des logiciels de qualité.

Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du système. C'est également un bon moyen de maîtriser sa complexité et d'assurer sa cohérence. Un modèle est un langage commun, précis, qui est connu par tous les membres de l'équipe et il est donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est essentielle pour aboutir à une compréhension commune aux différentes parties prenantes (notamment entre la maîtrise d'ouvrage et la maîtrise d'oeuvre informatique) et précise d'un problème donné.

Dans le domaine de l'ingénierie du logiciel, le modèle permet de mieux répartir les tâches et d'automatiser certaines d'entre elles. C'est également un facteur de réduction des coûts et des délais. Par exemple, les plateformes de modélisation savent maintenant exploiter les modèles pour faire de la génération de code (au moins au niveau du squelette) voire des allers-retours entre le code et le modèle sans perte d'information. Le modèle est enfin indispensable pour assurer un bon niveau de qualité et une maintenance efficace car, une fois mise en production, l'application va devoir être maintenue, probablement par une autre équipe et, qui plus est, pas nécessairement de la même société que celle ayant créée l'application. Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes non triviaux sont mieux modélisés par un ensemble de modèles indépendants. Selon les modèles employés, la démarche de modélisation n'est pas la même.

Dans ce chapitre, nous ferons une étude approfondie de l'ensemble des méthodes d'analyse et de conception existantes. Enfin nous effectuerons un choix parmi ces dites méthodes.

Une méthode fait intervenir essentiellement les concepts d'analyse et de conception.

Correspondant à la phase qui répond à la question « que fait le système », l'analyse est l'une des étapes les plus importantes et les plus difficiles de la modélisation. Elle permet de modéliser le domaine d'application, d'analyser l'existant et les contraintes de réalisation. Elle s'effectue par une abstraction et une séparation des problèmes. Elle peut être découpée en trois phases que sont :

Il s'agit d'identifier les acteurs et les cas d'utilisation, de structurer le modèle, et d'identifier les autres exigences.

Elle consiste à collecter des informations (interviews, lecture de documentation) et à la compréhension du domaine et du problème posé.

A ce niveau il s'agit de restituer les besoins dans un langage compréhensible par le client et de procéder à l'identification, à la structuration et à la définition d'un dictionnaire.

Dans cette phase il sera question d'aller à un niveau de spécification plus détaillé voire même plus formel des besoins. Elle sera d'une grande utilité pour le client mais aussi pour le développeur.

A la fin de cette phase d'analyse un modèle conceptuel sera disponible, lequel modèle sera un outil fondamental lors de la phase de conception.

Phase menée à la suite de l'analyse des besoins, la conception met en oeuvre tout un ensemble d'activités qui à partir d'une demande d'informatisation d'un processus permettent la conception, l'écriture et la mise au point d'un produit informatique (et donc de programmes informatiques) jusqu'à sa livraison au demandeur. Elle a comme objectifs de répondre à la question « comment faire le système ?» et de décomposer de façon modulaire le système à mettre en place. La conception définit l'architecture du logiciel. Elle définit par la même occasion chaque constituant du logiciel (Informations traitées, traitements effectués, résultats fournis, contraintes à respecter. A la suite un modèle logique utilisable à la phase d'implémentation est produit.

Cette phase consiste à la mise en oeuvre des programmes dans un langage de programmation conformément aux spécifications définies dans les phases précédentes. Elle renferme en son sein les phases de test et de mise au point (débogage). A la sortie il sera produit un modèle physique (collection de modules implémentés mais non testés, documentation de programmation expliquant le code).

Malgré la diversité des méthodes d'analyse et de conception, il est possible de les classer en trois catégories :

Avec cette méthode, le système étudié est abordé par les fonctions qu'il doit assurer plutôt que par les données qu'il doit gérer. Le processus de conception est vu comme un développement linéaire. Il y a décomposition systématique du domaine étudié en sous domaines, eux-mêmes décomposés en sous-domaines jusqu'à un niveau considéré élémentaire. SADT (Structured-Analysis-Design-Technique) en est un exemple.

Les méthodes systémiques sont des méthodes s'appuyant sur une approche systémique. Elles définissent différents niveaux de préoccupation ou d'abstraction et proposent de nombreux modèles complémentaires. Les méthodes systémiques sont souvent spécialisées pour la conception d'un certain type de systèmes. Comme exemple de méthode systémique nous pouvons citer MERISE, AXIAL ...

Ce sont des méthodes consistant à créer une représentation informatique des éléments du monde réel auxquels on s'intéresse, sans se préoccuper de l'implémentation, ce qui signifie indépendamment d'un langage de programmation. Il s'agit donc de déterminer les objets présents et d'isoler leurs données et les fonctions qui les utilisent. Pour cela des méthodes ont été mises au point. Entre 1970 et 1990, de nombreux analystes ont mis au point des approches orientées objets, si bien qu'en 1994 il existait plus de 50 méthodes objet. Toutefois seules 3 méthodes ont véritablement émergé :

Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling) visent à réduire le cycle de vie du logiciel (donc accélérer son développement) en développant une version minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et des tests tout au long du cycle de développement.

L'origine des méthodes agiles est liée à l'instabilité de l'environnement technologique et au fait que le client est souvent dans l'incapacité de définir ses besoins de manière exhaustive dès le début du projet. Le terme « agile » fait ainsi référence à la capacité d'adaptation aux changements de contexte et aux modifications de spécifications intervenant pendant le processus de développement. En 2001, 17 personnes mirent ainsi au point le manifeste agile dont la traduction est la suivante :

Grâce aux méthodes agiles, le client est pilote à part entière de son projet et obtient très vite une première mise en production de son logiciel. Ainsi, il est possible d'associer les utilisateurs dès le début du projet. Comme méthode agile nous pouvons citer eXtreme Programming (XP).

Pour l'analyse et la conception de notre application nous opterons pour une méthode orientée objet. Une méthode étant un assemblage d'une démarche et d'un langage de modélisation, nous allons choisir le tandem le plus adéquat.

RAD (Rapid Application Development) est une méthode de conduite de projet permettant de développer rapidement des applications de qualité. Aujourd'hui qualité et réactivité font partie des objectifs généraux de beaucoup d'entreprises. Cela entraine un certain nombre de projets, qui tout en apportant satisfaction aux utilisateurs, doivent être menés dans un délai court. C'est à cela que répond la méthode RAD.

La méthode RAD propose de remplacer le cycle de vie classique par un autre découpage temporaire. Le déroulement est d'abord linéaire, puis il suit le modèle de la spirale. Les étapes sont au nombre de cinq :

L'étape Initialisation : l'objectif est de sélectionner les acteurs pertinents, de structurer le travail en thèmes et d'amorcer une dynamique. Elle ne dépasse pas 15 jours.

L'étape Expression des besoins : l'objectif est de mettre à jour ce qui sera utile aux utilisateurs. On utilise la technique du JRP^1(*) qui organise le travail en session. La durée de cette étape est fonction du nombre d'utilisateurs concernés. Elle ne dépasse pas 30 jours.

L'étape Conception : l'objectif est de concevoir une solution. Les techniques utilisées sont le JAD^2(*) et le prototypage. L'étape ne dépasse pas 60 jours.

L'étape Construction : il s'agit, fonction par fonction, de construire un système viable. Les techniques utilisées sont la time-box^3(*) et le prototypage. Cette étape ne dépasse pas 120 jours.

L'étape Mise en oeuvre : des recettes partielles ont été faites à l'étape construction. Il s'agit ici d'officialiser une livraison globale, de l'optimiser éventuellement, d'installer le nouveau système et de faire le bilan du projet.

La méthode DSDM (Dynamic Software Development Method) a été mise au point en s'appuyant sur la méthode RAD afin de combler certaines de ses lacunes, notamment en offrant un canevas prenant en compte l'ensemble du cycle de développement.

· L'acceptation des produits livrés dépend directement de la satisfaction des besoins

La méthode du Processus Unifié (UP pour Unified Process) est un processus de développement itératif et incrémental, ce qui signifie que le projet est découpé en phases très courtes à l'issue de chacune desquelles une nouvelle version incrémentée est livrée.

Il s'agit d'une démarche s'appuyant sur la modélisation UML pour la description de l'architecture du logiciel (fonctionnelle, logicielle et physique) et la mise au point de cas d'utilisation permettant de décrire les besoins et exigences des utilisateurs.

RUP (Rational Unified Process) est une méthode de développement par itérations promue par la société Rational Software, rachetée par IBM. RUP propose une méthode spécifiant notamment la composition des équipes et le calendrier ainsi qu'un certain nombre de modèles de documents. RUP est l'une des plus célèbres implémentations de la démarche UP, livrée clé en main, permettant de donner un cadre de développement logiciel, répondant aux exigences fondamentales préconisées par les créateurs d'UML. RUP est une version commerciale d'UP.

La méthode XP (pour eXtreme Programming) définit un certain nombre de bonnes pratiques permettant de développer un logiciel dans des conditions optimales en plaçant le client au coeur du processus de développement, en relation étroite avec le client.

· Les équipes de développement travaillent directement avec le client sur des cycles très courts d'une à deux semaines maximum.

· Les livraisons de versions du logiciel interviennent très tôt et à une fréquence élevée pour maximiser l'impact des retours utilisateurs.

· L'équipe de développement travaille en collaboration totale sur la base de binômes.

· Des indicateurs permettent de mesurer l'avancement du projet afin de permettre la mise à jour du plan de développement.

Le choix de la démarche se fera en prenant en compte des critères essentiels de la plateforme à concevoir. Pour des raisons d'efficacité, de rapidité et d'analyse complète, nous opterons en effet pour un processus situé à mi-chemin entre UP (Unified Process), un cadre général très complet de processus de développement, et XP (eXtreme Programming), une approche minimaliste à la mode centrée sur le code.

UP (Unified Process) est une méthode générique de développement de logiciels.

Générique signifie qu'il est nécessaire d'adapter UP au contexte du projet, de l'équipe, du domaine et/ou de l'organisation (exemple: R.UP ou X.UP). C'est plus ou moins vrai pour toute méthode, qu'elle se définisse elle-même comme générique ou pas.

Le processus unifié est une démarche de développement logiciel : il regroupe les activités à mener pour transformer les besoins d'un utilisateur en système logiciel.

L'objectif principal d'un système logiciel est de rendre service à ses utilisateurs ; il faut par conséquent bien comprendre les désirs et les besoins des futurs utilisateurs. Le processus de développement sera donc centré sur l'utilisateur. Le terme utilisateur ne désigne pas seulement les utilisateurs humains mais également les autres systèmes. L'utilisateur représente donc une personne ou une chose dialoguant avec le système en cours de développement. Ce type d'interaction est appelé cas d'utilisation illustré par le schéma suivant :

Les cas d'utilisation font apparaître les besoins fonctionnels et leur ensemble constitue le modèle des cas d'utilisation qui décrit les fonctionnalités complètes du système.

Les cas d'utilisation ne sont pas un simple outil de spécification des besoins du système. Ils vont complètement guider le processus de développement à travers l'utilisation de modèles basés sur l'utilisation du langage UML.

Ø A partir du modèle des cas d'utilisation, les développeurs créent une série de modèles de conception et d'implémentation réalisant les cas d'utilisation.

Ø Chacun des modèles successifs est ensuite révisé pour en contrôler la conformité par rapport au modèle des cas d'utilisation.

Ø Enfin, les testeurs testent l'implémentation pour s'assurer que les composants du modèle d'implémentation mettent correctement en oeuvre les cas d'utilisation.

Les cas d'utilisation garantissent la cohérence du processus de développement du système. S'il est vrais que les cas d'utilisation guident le processus de développement, ils ne sont pas sélectionnés de façon isolée, mais doivent absolument être développés "en tandem" avec l'architecture du système.

Dès le démarrage du processus, on aura une vue sur l'architecture à mettre en place. L'architecture d'un système logiciel peut être décrite comme les différentes vues du système qui doit être construit. L'architecture logicielle équivaut aux aspects statiques et dynamiques les plus significatifs du système. L'architecture émerge des besoins de l'entreprise, tels qu'ils sont exprimés par les utilisateurs et autres intervenants et tels qu'ils sont reflétés par les cas d'utilisation.

Tout produit est à la fois forme et fonction. Les cas d'utilisation doivent une fois réalisés, trouver leur place dans l'architecture. L'architecture doit prévoir la réalisation de tous les cas d'utilisation. L'architecture et les cas d'utilisation doivent évoluer de façon concomitante.

ü L'architecte crée une ébauche grossière de l'architecture, en partant de l'aspect qui n'est pas propre aux cas d'utilisation (plateforme..). Bien que cette partie de l'architecture soit indépendante des cas d'utilisation, l'architecte doit avoir une compréhension globale de ceux-ci avant d'en esquisser l'architecture.

ü Il travaille ensuite, sur un sous ensemble des cas d'utilisations identifiés, ceux qui représentent les fonctions essentielles du système en cours de développement.

ü L'architecture se dévoile peu à peu, au rythme de la spécification et de la maturation des cas d'utilisation, qui favorisent, à leur tour, le développement d'un nombre croissant de cas d'utilisation.

Le développement d'un produit logiciel destiné à la commercialisation est une vaste entreprise qui peut s'étendre sur plusieurs mois. On ne va pas tout développer d'un coup. On peut découper le travail en plusieurs parties qui sont autant de mini projets, chacun d'entre eux représentant une itération qui donne lieu à un incrément.

Une itération désigne la succession des étapes de l'enchaînement d'activités, tandis qu'un incrément correspond à une avancée dans les différents stades de développement.

Le choix de ce qui doit être implémenté au cours d'une itération repose sur deux facteurs :

· Une itération prend en compte un certain nombre de cas d'utilisations qui, ensemble, améliorent l'utilisabilité du produit à un certain stade de développement.

Un incrément constitue souvent un additif. A chaque itération, les développeurs identifient et spécifient les cas d'utilisations pertinents, créent une conception en se laissant guider par l'architecture choisie, implémentent cette conception sous forme de composants et vérifient que ceux-ci sont conformes aux cas d'utilisation. Dés qu'une itération répond aux objectifs fixés le développement passe à l'itération suivante. Pour rentabiliser le développement il faut sélectionner les itérations nécessaires pour atteindre les objectifs du projet. Ces itérations devront se succéder dans un ordre logique. Un projet réussi suivra un déroulement direct établi dès le début par les développeurs et dont ils ne s'éloigneront que de façon très marginale. L'élimination des problèmes imprévus fait partie des objectifs de réduction des risques. Les avantages d'un processus unifié contrôlé sont :

Ø la limitation des coûts, en termes de risques, aux strictes dépenses liées à une itération,

Ø la limitation des risques de retard de mise sur le marché du produit développé (identification des problèmes dès les premiers stades de développement et non en phase de test comme avec l'approche « classique »),

Ø l'accélération du rythme de développement grâce à des objectifs clairs et à court terme,

Ø la prise en compte du fait que les besoins des utilisateurs et les exigences correspondantes ne peuvent être intégralement définis à l'avance et se dégagent peu à peu des itérations successives.

L'architecture fournit la structure qui servira de cadre au travail effectué au cours des itérations, tandis que les cas d'utilisation définissent les objectifs et orientent le travail de chaque itération. Il ne faut donc pas mésestimer l'un des trois concepts.

Le processus unifié répète un certain nombre de fois une série de cycles. Tout cycle se conclut par la livraison d'une version du produit aux clients et s'articule en 4 phases : création, élaboration, construction et transition, chacune d'entre elles se subdivisant à son tour en itérations.

Chaque cycle se traduit par une nouvelle version du système. Ce produit se compose d'un corps de code source réparti sur plusieurs composants pouvant être compilés et exécutés et s'accompagne de manuels et de produits associés. Pour mener efficacement le cycle, les développeurs ont besoin de construire toutes les représentations du produit logiciel :

Modèle des cas d'utilisation	Expose les cas d'utilisation et leurs relations avec les utilisateurs
Modèle d'analyse	Détaille les cas d'utilisation et procède à une première répartition du comportement du système entre divers objets
Modèle de conception	Définit la structure statique du système sous forme de sous système, classes et interfaces ; Définit les cas d'utilisation réalisés sous forme de collaborations entre les sous systèmes les classes et les interfaces
Modèle d'implémentation	Intègre les composants (code source) et la correspondance entre les classes et les composants
Modèle de déploiement	Définit les noeuds physiques des ordinateurs et l'affectation de ces composants sur ces noeuds.
Modèle de test	Décrit les cas de test vérifiant les cas d'utilisation
Représentation de l'architecture	Description de l'architecture

Tous ces modèles sont liés. Ensemble, ils représentent le système comme un tout. Les éléments de chacun des modèles présentent des dépendances de traçabilité ; ce qui facilite la compréhension et les modifications ultérieures.

Première phase du cycle de vie du processus unifié, la création traduit une idée en vision de produit fini et présente l'étude de rentabilité pour ce produit. Elle essaie de répondre à un certain nombre de questions : Que va faire le système pour les utilisateurs ? A quoi peut ressembler l'architecture d'un tel système ? Quels sont l'organisation et les coûts du développement de ce produit ? C'est à ce niveau où les principaux cas d'utilisation seront spécifiés. L'identification des risques majeurs, la mise sur place d'une architecture provisoire du système à concevoir et la préparation de la phase d'élaboration seront les principales tâches à effectuer durant cette étape de la création.

Elle permet de préciser la plupart des cas d'utilisation et de concevoir l'architecture du système. L'architecture doit être exprimée sous forme de vue de chacun des modèles. Lors de cette phase une architecture de référence sera conçue. Au terme de cette étape, le chef de projet doit être en mesure de prévoir les activités et d'estimer les ressources nécessaires à l'achèvement du projet.

C'est le moment où l'on construit le produit. L'architecture de référence se métamorphose en produit complet, elle est maintenant stable. Le produit contient tous les cas d'utilisation que les chefs de projet, en accord avec les utilisateurs ont décidé de mettre au point pour cette version. Celle ci doit encore avoir des anomalies qui peuvent être en partie résolue lors de la phase de transition.

Le produit est en version bêta. Un groupe d'utilisateurs essaye le produit et détecte les anomalies et défauts. Cette phase suppose des activités comme la fabrication, la formation des utilisateurs clients, la mise en oeuvre d'un service d'assistance et la correction des anomalies constatées (ou le report de leur correction à la version suivante).

L'eXtreme Programming ou XP, est une méthode de développement de projet mise au point à la fin des années 90 par Kent Beck, Ward Cunningham et Ron Jeffries.
XP doit son nom au fait qu'elle place l'activité de programmation au centre du projet, et qu'elle obtient ses résultats en combinant et en poussant à l'extrême certaines pratiques de développement. XP est un ensemble de pratiques qui couvre une grande partie des activités de la réalisation d'un logiciel, de la programmation proprement dite à la planification du projet, en passant par l'organisation de l'équipe de développement et les échanges avec le client. Ces pratiques n'ont en soi rien de révolutionnaire : il s'agit simplement de pratiques de bon sens, mises en oeuvre par des développeurs ou des chefs de projet expérimentés, telles que :

· Un utilisateur à plein-temps dans la salle projet. Ceci permet une communication intensive et permanente entre les clients et les développeurs, aussi bien pour l'expression des besoins que pour la validation des livraisons.

· Écrire le test unitaire avant le code qu'il doit tester, afin d'être certain que le test sera systématiquement écrit et non pas négligé.

· Programmer en binôme, afin d'homogénéiser la connaissance du système au sein des développeurs, ainsi que de permettre aux débutants d'apprendre des experts. Le code devient ainsi une propriété collective et non individuelle que tous les développeurs ont le droit de modifier.

· Intégrer de façon continue, pour ne pas retarder à la fin du projet le risque majeur de l'intégration des modules logiciels écrits par des équipes ou des personnes différentes.

Communication : La communication est la composante fondamentale de tout travail en équipe. XP installe la communication dans le projet à tous les niveaux.

Simplicité : Communication et retour d'information : ces dispositions sont menacées, à mesure que le produit évolue et s'accroît, par la lourdeur et l'inertie du processus. Pour cette raison, XP érige la simplicité en véritable discipline, tant au niveau de la conception que du processus lui-même (scénarios utilisateur, séances de planifications, propriété collective du code, pas de spécialisations techniques).

Feedback : Le retour d'information permet de tracer et d'ajuster le processus en vue d'améliorer la qualité, la maintenance et la productivité. A chacune des tâches de production, XP câble un mécanisme ou une pratique permettant de valider cette production de manière quasiment continue.

Courage : La force d'une équipe même dotée d'une approche efficace ne se mesure pas tant à ce qu'elle fait lorsque tout va bien, qu'à la manière dont elle affronte les difficultés. Pour cette raison XP valorise également le Courage.

Elle est bien adaptée pour des projets de taille moyenne où le contexte (besoins utilisateurs, technologies informatiques) évolue en permanence.

L'eXtreme Programming repose sur des cycles rapides de développement (des itérations de quelques semaines) dont les étapes sont les suivantes :

· une phase d'exploration qui détermine les scénarios clients qui seront fournis pendant cette itération ;

· une phase de planning où l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels ;

· une phase de mise en production où chaque développeur s'attribue des tâches et les réalise avec un binôme ;

· une phase de maintenance lorsque tous les tests fonctionnels passent, le produit est livré.

Le cycle se répète tant que le client peut fournir des scénarios à livrer. La première livraison est généralement plus importante et n'est réalisée qu'après quelques itérations. Après la première mise en production, les itérations peuvent devenir plus courtes (une semaine par exemple).

La problématique que pose la mise en oeuvre d'UML est simple : comment passer de l'expression des besoins au code de l'application ? Comment obtenir le plus efficacement possible un code informatique opérationnel, complet, testé, et qui réponde parfaitement aux besoins exprimés par les utilisateurs ?

Dans un premier temps, les besoins vont être modélisés au moyen des cas d'utilisation UML. Ils seront également représentés de façon plus concrète par une maquette d'IHM (Interface Homme Machine) destinée à faire réagir les futurs utilisateurs.

Dans le cadre des systèmes orientés-objets, la structure du code est définie par les classes logicielles et leurs regroupements en ensembles appelés packages. Nous avons donc besoin de diagrammes représentant les classes logicielles et montrant les données qu'elles contiennent (attributs), les services qu'elles rendent (opérations) ainsi que leurs relations. UML propose les diagrammes de classes pour véhiculer toutes ces informations.

Les diagrammes de classes de conception représentent bien la structure statique du code, par le biais des attributs et des relations entre classes, mais ils contiennent également les opérations (méthodes) qui décrivent les responsabilités dynamiques des classes logicielles. L'attribution des bonnes responsabilités aux bonnes classes est l'un des problèmes les plus délicats de la conception orientée-objet. Pour chaque service ou fonction, il faut décider quelle est la classe qui va le contenir. Nous devons ainsi répartir tout le comportement du système entre les classes de conception et décrire les collaborations induites.

Les diagrammes d'interactions UML (séquence ou collaboration) sont particulièrement utiles au concepteur pour représenter graphiquement ses décisions d'allocation de responsabilités. Chaque diagramme d'interaction va ainsi représenter un ensemble d'objets de classes différentes collaborant dans le cadre d'un scénario d'exécution du système. Dans ce genre de diagramme, les objets communiquent en s'envoyant des messages qui invoquent des opérations sur les objets récepteurs.

On peut donc suivre visuellement les interactions dynamiques entre objets, et les traitements réalisés par chacun. Les diagrammes d'interaction aident également à écrire le code à l'intérieur des opérations, en particulier les appels d'opérations imbriqués. La figure suivante ajoute une étape du côté du code, mais ne nous dit pas encore comment relier tout cela aux cas d'utilisation.

Comment passer des cas d'utilisation aux diagrammes d'interaction ? Ce n'est pas simple ni direct car les cas d'utilisation sont au niveau d'abstraction des besoins utilisateurs alors que les diagrammes d'interaction se placent au niveau de la conception objet. Il faut donc au moins une étape intermédiaire.

Chaque cas d'utilisation est décrit textuellement de façon détaillée, mais donne également lieu à un diagramme de séquence représentant graphiquement la séquence des interactions entre les acteurs et le système vu comme une boîte noire, dans le cadre du scénario nominal. Nous appellerons ce diagramme : diagramme de séquence système.

Par la suite, en remplaçant le système vu comme une boîte noire par un ensemble choisi d'objets de conception, nous décrirons l'attribution des responsabilités dynamiques, tout en conservant une traçabilité forte avec les cas d'utilisation. La figure ci-après montre ainsi les diagrammes de séquence système en tant que lien important entre les cas d'utilisation et les diagrammes d'interaction.

Mais comment trouver ces fameuses classes de conception qui interviennent dans les diagrammes d'interactions ?

Les classes logicielles représentant l'informatisation des concepts métier manipulés par les experts du domaine et les utilisateurs sont assez directement trouvées par une analyse du domaine. Pour matérialiser cette analyse, nous allons construire un modèle du domaine, sorte de glossaire détaillé et formalisé en UML des concepts fondamentaux de l'espace du problème. Ces concepts, leurs attributs et leurs relations vont être décrits en UML par un diagramme de classes simplifié utilisant des conventions particulières. Comme indiqué sur la figure suivante, le modèle du domaine fournit une partie des classes de conception, celles correspondant directement aux concepts métier. Il découle des cas d'utilisation et de l'analyse des besoins

Mais le modèle du domaine à lui seul ne permet pas d'identifier les principales classes d'IHM ni celles qui décrivent la cinématique de l'application. Le chaînon manquant de notre démarche s'appelle les diagrammes de classes participantes. Il s'agit là encore de diagrammes de classes UML qui décrivent, cas d'utilisation par cas d'utilisation, les trois principales classes d'analyse et leurs relations.

· Les classes qui permettent les interactions entre l'application et ses utilisateurs sont qualifiées de « dialogues ». Ce sont typiquement les écrans proposés à l'utilisateur : les formulaires de saisie, les résultats de recherche, etc. Elles proviennent directement de l'analyse de la maquette.

· Celles qui contiennent la cinématique de l'application seront appelées « contrôles ». Elles font la transition entre les dialogues et les classes métier, en permettant aux écrans de manipuler des informations détenues par un ou plusieurs objets métier.

· Celles qui représentent les règles métier sont qualifiées d'« entités ». Elles proviennent directement du modèle du domaine, mais sont confirmées et complétées cas d'utilisation par cas d'utilisation.

Un avantage important de cette technique pour le chef de projet consiste en la possibilité de découper le travail de son équipe d'analyste suivant les différents cas d'utilisation, plutôt que de vouloir tout traiter d'un bloc. En outre, le modèle du domaine joue le rôle de référence commune et d'arbitre en ce qui concerne les entités découvertes par les différentes équipes. Comme l'illustre la figure ci-après, les diagrammes de classes participantes sont particulièrement importants car ils font la jonction entre le les cas d'utilisation, le modèle du domaine, la maquette et les diagrammes de conception logicielle (diagrammes d'interaction et diagrammes de classes).

Pour que le tableau soit complet, il nous reste à détailler une exploitation supplémentaire de la maquette. Elle va nous permettre de réaliser des diagrammes dynamiques représentant de manière formelle l'ensemble des chemins possibles entre les principaux écrans proposés à l'utilisateur. Ces diagrammes s'appellent des diagrammes d'activités de navigation.
La trame globale de la démarche est ainsi finalisée, comme indiqué sur la figure suivante.

UML (en anglais Unified Modeling Language, « langage de modélisation unifié ») est un langage graphique de modélisation des données et des traitements. C'est une formalisation très aboutie et non-propriétaire de la modélisation objet utilisée en génie logiciel. UML est l'accomplissement de la fusion des meilleures approches de la modélisation objet (Booch, OMT, OOSE) effectuée en 1995. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard défini par l'OMG (Object Management Group).

UML a démarré avec la version 0.8 intégrant les méthodes BOOCH 93 et OMT. Par la suite il y a eu l'avènement de la version 0.9 ayant intégré la méthode OOSE. La version 1.0, proposé à l'OMG en 1996, fut finalement standardisée en 1997 sous la version 1.1. Depuis cette année il ya eu quatre révisions du standard (de UML 1.1 à UML 1.5 en 2003). Les dernières améliorations étant conséquentes, UML est passé à une nouvelle version : UML 2.0 (ou UML 2), abrégé souvent en U2. Cette figure ci-dessous montre l'évolution des versions d'UML depuis sa genèse.

On appelle objet un élément matériel ou immatériel, dans la réalité étudiée, qui satisfait aux principes de distinction, de permanence et d'activité. Cela entraine qu'un objet possède une identité, un état et un comportement. Un objet communique avec ses utilisateurs (ou clients) par le biais de son interface. L'interface d'un objet est la liste des services qu'il peut rendre et des ressources qu'il souhaite mettre à la disposition de ses clients.

Une classe est un ensemble d'objet sur lesquels on peut reconnaître des similitudes dans le champ d'étude. Ces similitudes portent sur la façon de les identifier, sur les types d'états qu'ils peuvent prendre et sur le rôle qu'ils jouent.

Lors de la modélisation d'un système d'information certains objets sont porteurs d'informations concrètes, manipulées, transmises ou mémorisées. On les qualifie d'objets informationnels. Une entité est donc un ensemble d'objets sur lesquels on peut reconnaître la même structure et qui sont gérés de la même façon

UML n'emploie pas le terme d'utilisateur mais d'acteur. Les acteurs d'un système sont les entités externes à ce système qui interagissent (saisie de données, réception d'information, ...) avec lui. Les acteurs sont donc à l'extérieur du système et dialoguent avec lui. Ces acteurs permettent de cerner l'interface que le système va devoir offrir à son environnement. Oublier des acteurs ou en identifier de faux conduit donc nécessairement à se tromper sur l'interface et donc la définition du système à produire.

Le terme processus vient du latin « progrès » et signifie littéralement « aller de l'avant » ; cela évoque l'idée d'une marche progressive ou d'un plan déterminé à l'avance. On appelle processus l'organisation d'un ensemble finalisé d'activités effectuées par des acteurs et mettant en jeu des entités, pour répondre à un type d'événement.

Diverses perspectives ou vues peuvent être prises en compte dans la modélisation d'un système d'informations. Le langage UML en a défini cinq (05) qui sont complémentaires et qui guident l'utilisation des concepts objets : il s'agit de l'architecture 4+1 centrée sur la vue utilisateur représentée par la figure ci-dessous.

Cette vue appelée vue de haut niveau se concentre sur l'abstraction et l'encapsulation. C'est à ce niveau que s'effectue la modélisation des éléments et mécanismes principaux du système. La vue logique permet d'identifier les éléments du domaine, ainsi que les relations et interactions entre ces éléments : les éléments du domaine étant le(s) métier(s) de l'entreprise. Ils sont d'une importance capitale dans la mission future du système, ils gagnent à être réutilisés (ils représentent un savoir-faire). Cette vue permet aussi d'organiser, (selon des critères purement logiques), les éléments du domaine en "catégories" : pour répartir les tâches dans les équipes, regrouper ce qui peut être générique, isoler ce qui est propre à une version donnée, etc.

Cette vue de bas niveau (aussi appelée "vue de réalisation"), montre : L'allocation des éléments de modélisation dans des modules (fichiers sources, bibliothèques dynamiques, bases de données, exécutables, etc.). En d'autres termes, cette vue identifie les modules qui réalisent (physiquement) les classes de la vue logique. Elle définit aussi l'organisation des composants, c'est-à dire la distribution du code en gestion de configuration, les dépendances entre les composants... Les contraintes de développement (bibliothèques externes...). La vue des composants montre aussi l'organisation des modules en "sous-systèmes", les interfaces des sous-systèmes et leurs dépendances (avec d'autres sous-systèmes ou modules).

Cette vue est d'une très grande importante dans les environnements multitâches ; elle montre :

Cette vue très importante dans les environnements distribués, décrit les ressources matérielles et la répartition du logiciel dans ces ressources :

o la disposition et nature physique des matériels, ainsi que leurs performances,

o les exigences en termes de performances (temps de réponse, tolérance aux fautes et pannes...).

Cette vue (dont le nom exact est "vue des cas d'utilisation"), guide toutes les autres. Dessiner le plan (l'architecture) d'un système informatique n'est pas suffisant, il faut le justifier ! Cette vue définit les besoins des clients du système et centre la définition de l'architecture du système sur la satisfaction (la réalisation) de ces besoins. A l'aide de scénarios et de cas d'utilisation, cette vue conduit à la définition d'un modèle d'architecture pertinent et cohérent. Cette vue est la "colle" qui unifie les quatre autres vues de l'architecture. Elle motive les choix, permet d'identifier les interfaces critiques et force à se concentrer sur les problèmes importants.

UML n'est pas une méthode (i.e. une description normative des étapes de la modélisation) : ses auteurs ont en effet estimé qu'il n'était pas opportun de définir une méthode en raison de la diversité des cas particuliers. Ils ont préféré se borner à définir un langage graphique qui permet de représenter, de communiquer les divers aspects d'un système d'information (aux graphiques sont, bien sûr, associés des textes qui expliquent leur contenu). UML est donc un métalangage car il fournit les éléments permettant de construire le modèle qui, lui, sera le langage du projet.

Il est impossible de donner une représentation graphique complète d'un logiciel, ou de tout autre système complexe, de même qu'il est impossible de représenter entièrement une statue (à trois dimensions) par des photographies (à deux dimensions). Mais il est possible de donner sur un tel système des vues partielles, analogues chacune à une photographie d'une statue, et dont la juxtaposition donnera une idée utilisable en pratique sans risque d'erreur grave.

UML 2.0 en a rajouté quatre. Ces treize types de diagrammes représentent autant de vues distinctes pour représenter des concepts particuliers du système d'information. Ils se répartissent en deux grands groupes :

· diagramme de structures composites (Composite structure diagram) rajouté par UML 2.0

o diagramme global d'interaction (Interaction overview diagram) rajouté par UML 2.0

Ces diagrammes, d'une utilité variable selon les cas, ne sont pas nécessairement tous produits à l'occasion d'une modélisation. Les plus utiles pour la maîtrise d'ouvrage sont les diagrammes d'activités, de cas d'utilisation, de classes, d'objets, de séquence et d'états transitions. Les diagrammes de composants, de déploiement et de communication sont surtout utiles pour la maîtrise d'oeuvre à qui ils permettent de formaliser les contraintes de la réalisation et la solution technique. Dans la suite nous allons présenter les diagrammes utilisés dans notre modélisation.

Le diagramme de classes est considéré comme le plus important de la modélisation orienté objet et le seul obligatoire lors d'une telle modélisation. Il montre la structure interne d'un système à mettre en place. Il permet de fournir une représentation abstraite des objets du système qui vont interagir ensemble pour réaliser les cas d'utilisation. Il est important de noter qu'un même objet peut très bien intervenir dans la réalisation de plusieurs cas d'utilisation. Les cas d'utilisation ne réalisent donc pas une partition des classes du diagramme de classes. Un diagramme de classes n'est donc pas adapté (sauf cas particulier) pour détailler, décomposer, ou illustrer la réalisation d'un cas d'utilisation particulier. Il s'agit d'une vue statique car on ne tient pas compte du facteur temporel dans le comportement du système. Le diagramme de classes modélise les concepts du domaine d'application ainsi que les concepts internes créés de toutes pièces dans le cadre de l'implémentation d'une application. Chaque langage de Programmation Orientée Objets donne un moyen spécifique d'implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d'un langage de programmation particulier. Les principaux éléments de cette vue statique sont les classes et leurs relations : association, généralisation et plusieurs types de dépendances, telles que la réalisation et l'utilisation.

Bien souvent, la maîtrise d'ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d'exprimer leurs besoins. C'est précisément le rôle des diagrammes de cas d'utilisation qui permettent de recueillir, d'analyser et d'organiser les besoins, et de recenser les grandes fonctionnalités d'un système. Il s'agit donc de la première étape UML d'analyse d'un système.

Un diagramme de cas d'utilisation capture le comportement d'un système, d'un sous-système, d'une classe ou d'un composant tel qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en unités cohérentes, les cas d'utilisation, ayant un sens pour les acteurs. Les cas d'utilisation permettent d'exprimer le besoin des utilisateurs d'un système, ils sont donc une vision orientée utilisateur de ce besoin au contraire d'une vision informatique.

Il ne faut pas négliger cette première étape pour produire un logiciel conforme aux attentes des utilisateurs. Pour élaborer les cas d'utilisation, il faut se fonder sur des entretiens avec les utilisateurs.

· Acteur : un acteur est l'idéalisation d'un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système.

· Cas d'utilisation : un cas d'utilisation est une unité cohérente représentant une fonctionnalité visible de l'extérieur. Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie. Un cas d'utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service.

· Association : Une association est le chemin de communication entre un acteur et un cas d'utilisation.

Le diagramme de séquence est une représentation intuitive lorsque l'on souhaite concrétiser des interactions entre deux entités (deux sous-systèmes ou deux classes d'un futur logiciel). Ils permettent à l'architecte/designer de créer au fur et à mesure sa solution. Cette représentation intuitive est également un excellent vecteur de communication dans une équipe d'ingénierie pour discuter cette solution.

Les diagrammes de séquence peuvent également servir à la problématique de test. Les traces d'exécution d'un test peuvent en effet être représentées sous cette forme et servir de comparaison avec les diagrammes de séquence réalisés lors des phases d'ingénierie. Le diagramme de séquence permet aussi de représenté un scénario^4(*) d'un cas d'utilisation.

Les diagrammes d'activités permettent de mettre l'accent sur les traitements. Ils sont donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de flots de données. Ils permettent ainsi de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation.

Les diagrammes d'activités sont relativement proches des diagrammes d'états-transitions^5(*) dans leur présentation, mais leur interprétation est sensiblement différente. Les diagrammes d'états-transitions sont orientés vers des systèmes réactifs, mais ils ne donnent pas une vision satisfaisante d'un traitement faisant intervenir plusieurs classeurs et doivent être complétés, par exemple, par des diagrammes de séquence. Au contraire, les diagrammes d'activités ne sont pas spécifiquement rattachés à un classeur particulier. Ils permettent de spécifier des traitements a priori séquentiels et offrent une vision très proche de celle des langages de programmation impératifs comme C++ ou Java.

Dans la phase de conception, les diagrammes d'activités sont particulièrement adaptés à la description des cas d'utilisation. Plus précisément, ils viennent illustrer et consolider la description textuelle des cas d'utilisation. De plus, leur représentation sous forme d'organigrammes les rend facilement intelligibles et beaucoup plus accessibles que les diagrammes d'états-transitions.

Les diagrammes d'activités sont également utiles dans la phase de réalisation car ils permettent une description si précise des traitements, qu'elle autorise la génération automatique du code.

Adopté en Juin 2004, UML2.0 ou UML2 qui est une révision majeure d'UML1.x, est déjà supporté par un nombre important d'ateliers UML.

Le tableau ci-dessous synthétise l'ampleur des changements intervenus entre UML1.4 et UML2.0. Les éléments nouveaux ou très impactés sont notés "+++", cependant que les moins impactés sont notés "-".

Modèle	Degré d'évolution	Commentaire
Flux d'information	+++	Nouveauté
Diagramme d'activité	+++	Extensions et enrichissement pour la modélisation des processus et "workflow"
Diagramme d'interaction	+++	Structuration et Structures de contrôle sur les diagrammes de séquence.
Diagramme de collaboration	++	Unification avec "parts" et "ports"
Diagramme de classes	++	Nouveautés: parts, ports, structure interne
Diagramme de déploiement	+	Refonte et généralisation
Diagramme d'état	+	Structuration
Diagramme d'état de protocole	+	Formalisation, State invariant, pré et post conditions
Diagramme des cas d'utilisation	-	Quasi inchangé pour l'utilisateur final.

Les diagrammes de séquence (interaction diagram) ont été totalement refondus, afin de leur donner plus de précision et de capacité de modélisation. Il est maintenant possible de décomposer des diagrammes de séquence en "sous diagrammes de séquence" et d'employer des structures de contrôle au sein des diagrammes de séquence. Leur extension a surtout été inspirée par les besoins des domaines des télécoms, qui doivent exprimer finement des protocoles. Les diagrammes de collaboration sont peu utilisés par les praticiens d'UML1.4. Peu s'intéressent donc à leur évolution, qui du point de vue de la représentation reste stable. Les diagrammes de classe ont bénéficié de quelques extensions. Dans une grande majorité de cas, ceux-ci restent inchangés par rapport à UML1.4. Lorsque des besoins de modélisation architecturale apparaissent, alors de nouvelles notions sont utilisées, comme par exemple les composants, les parts et les ports. Les diagrammes de déploiement corrigent des insuffisances d'UML1.x. Les notions d'artefact permettent de modéliser la chaîne de production d'une application, en décidant des éléments gérés et produits, comme par exemple des librairies ou des exécutables. Les diagrammes d'état peuvent être structurés et factorisés pour être réutilisés. On distingue maintenant les diagrammes d'état de protocole, qui permet de décrire le cycle de vie des objets. Les diagrammes de cas d'utilisation enfin, ne présentent pas d'évolutions notables.

Deuxième partie : Analyse et conception

Ø Le monde des services pour mobiles : qui renferme une étude du soubassement infrastructurel des services (appareil portable et réseaux mobiles) et un aperçu sur les services existants.

Ø Spécifications détaillées de notre plateforme : chapitre où nous exprimons de manière claire et précise ce que nous voulons de notre plateforme ;

Ø Conception de la plateforme : chapitre dans lequel nous mettons en pratique la démarche de modélisation choisie pour concevoir la plateforme.

Chapitre 3 : Le monde des services pour mobiles

Naguère apanage des opérateurs de téléphonie et constructeurs d'appareils portables, les applications pour mobiles sont devenues le domaine de prédilection des majors de l'informatique au nom de la convergence informatique - télécommunication. Parmi ceux-ci, nous pouvons citer Microsoft avec son système d'exploitation Windows Mobile, Google concepteur d'Androïd et Yahoo pour sa suite Yahoo Mobile.

A côté de ces majors, de nombreux fournisseurs de service ont aussi investi ce secteur. Nous allons, ci-après, décrire le soubassement infrastructurel de ces services, ensuite nous décrirons ces services en tant que tels.

Un téléphone mobile (ou simplement mobile), également nommé téléphone portable ou portable (ce qui peut créer des confusions avec l' ordinateur portable), permet de communiquer par voix sans être relié par câble à un central.

Les sons ne sont pas transmis directement. La voix est codée puis resynthétisée au niveau de la réception. D'où les bruits incongrus parfois en cas de mauvaise réception (bruit de ressorts). La transmission se fait par ondes électromagnétiques avec un réseau spécifique. On peut donc communiquer de tout lieu où une antenne de relais capte les émissions de l'appareil utilisé.

Depuis son apparition à aujourd'hui, le téléphone portable a énormément évolué. C'est parti d'un objet très simple juste pour téléphoner, à un objet très complexe qui devient maintenant télévision. On parle de Smartphones ou téléphones intelligents.

Cependant l'utilisation de certaines fonctionnalités repose sur la disponibilité d'un réseau approprié.

2. Les réseaux téléphoniques : une infrastructure évolutive pour une stratégie orientée services

Plusieurs types de réseau se sont succédés dans le monde de la téléphonie, chacun apportant des améliorations dans la qualité de service par rapport à son prédécesseur. Nous allons décrire dans cette section les principaux réseaux qui ont marqué la téléphonie et mettre en évidence l'amélioration du débit mobile à travers leur succession.

Le réseau GSM (Global System for Mobile communications) constitue au début du 21ème siècle le standard de téléphonie mobile le plus utilisé. Successeur du Radiocom 2000 depuis le 28 juillet 2000, il s'agit d'un standard de téléphonie dit « de seconde génération » (2G) car, contrairement à la première génération de réseau de téléphones portables, les communications fonctionnent selon un mode entièrement numérique.

Il existe d'autres standards 2G tels que le CDMA (Code Division Multiple Access), utilisant une technique d'étalement de spectres permettant de diffuser un signal radio sur une grande gamme de fréquences et le TDMA (Time Division Multiple Access), utilisant une technique de découpage temporel des canaux de communication, afin d'augmenter le volume de données transmis simultanément

Baptisé « Groupe Spécial Mobile » à l'origine de sa normalisation en 1982, le GSM est devenu une norme internationale nommée « Global System for Mobile communications » en 1991. Il utilise les bandes de fréquences 900 MHz et 1800 MHz. On parle alors de GSM 900 ou GSM 1800 (appelé aussi DCS 1800) suivant la bande utilisée.

La norme GSM autorise un débit maximal de 9,6 kbps, ce qui permet de transmettre la voix ainsi que des données numériques de faible volume, par exemple des messages textes (SMS, pour Short Message Service) ou des messages multimédias (MMS, pour Multimedia Message Service).

Les réseaux de téléphonie mobile sont basés sur la notion de cellules, c'est-à-dire des zones circulaires se chevauchant afin de couvrir une zone géographique.

Les réseaux cellulaires reposent sur l'utilisation d'un émetteur-récepteur central au niveau de chaque cellule, appelée « station de base » (en anglais Base Transceiver Station, notée BTS).

Plus le rayon d'une cellule est petit, plus la bande passante disponible est élevée. Ainsi, dans les zones urbaines fortement peuplées, des cellules d'une taille pouvant avoisiner quelques centaines de mètres seront présentes, tandis que de vastes cellules d'une trentaine de kilomètres permettront de couvrir les zones rurales.

Dans un réseau cellulaire, chaque cellule est entourée de 6 cellules voisines (c'est la raison pour laquelle on représente généralement une cellule par un hexagone). Afin d'éviter les interférences, des cellules adjacentes ne peuvent utiliser la même fréquence. En pratique, deux cellules possédant la même gamme de fréquences doivent être éloignées d'une distance représentant deux à trois fois le diamètre de la cellule.

Dans un réseau GSM, le terminal de l'utilisateur est appelé station mobile. Une station mobile est composée d'une carte SIM (Subscriber Identity Module), permettant d'identifier l'usager de façon unique, et d'un terminal mobile, c'est-à-dire l'appareil de l'usager (la plupart du temps un téléphone portable).

Les terminaux (appareils) sont identifiés par un numéro d'identification unique de 15 chiffres appelé IMEI (International Mobile Equipment Identity). Chaque carte SIM possède également un numéro d'identification unique (et secret) appelé IMSI (International Mobile Subscriber Identity). Ce code peut être protégé à l'aide d'une clé de 4 chiffres appelés code PIN.

La carte SIM permet ainsi d'identifier chaque utilisateur, indépendamment du terminal utilisé lors de la communication avec une station de base. La communication entre une station mobile et la station de base se fait par l'intermédiaire d'un lien radio, généralement appelé interface air (ou plus rarement interface Um).

L'ensemble des stations de base d'un réseau cellulaire est relié à un contrôleur de stations (en anglais Base Station Controller, noté BSC), chargé de gérer la répartition des ressources. L'ensemble constitué par le contrôleur de stations et les stations de base connectées constituent le sous-système radio (en anglais BSS pour Base Station Subsystem).

Enfin, les contrôleurs de stations sont eux-mêmes reliés physiquement au centre de commutation du service mobile (en anglais MSC pour Mobile Switching Center), géré par l'opérateur téléphonique, qui les relie au réseau téléphonique public et à internet. Le MSC appartient à un ensemble appelé sous-système réseau (en anglais NSS pour Network Station Subsystem), chargé de gérer les identités des utilisateurs, leur localisation et l'établissement de la communication avec les autres abonnés.

Le MSC est généralement relié à des bases de données assurant des fonctions complémentaires :

· Le registre des abonnés locaux (noté HLR pour Home Location Register): il s'agit d'une base de données contenant des informations (position géographique, informations administratives, etc.) sur les abonnés inscrits dans la zone du commutateur (MSC).

· Le Registre des abonnés visiteurs (noté VLR pour Visitor Location Register): il s'agit d'une base de données contenant des informations sur les autres utilisateurs que les abonnés locaux. Le VLR rapatrie les données sur un nouvel utilisateur à partir du HLR correspondant à sa zone d'abonnement. Les données sont conservées pendant tout le temps de sa présence dans la zone et sont supprimées lorsqu'il la quitte ou après une longue période d'inactivité (terminal éteint).

· Le registre des terminaux (noté EIR pour Equipement Identity Register) : il s'agit d'une base de données répertoriant les terminaux mobiles.

· Le Centre d'authentification (noté AUC pour Authentification Center) : il s'agit d'un élément chargé de vérifier l'identité des utilisateurs.

Le réseau cellulaire ainsi formé est prévu pour supporter la mobilité grâce à la gestion du handover, c'est-à-dire le passage d'une cellule à une autre.

Enfin, les réseaux GSM supportent également la notion d'itinérance (en anglais roaming), c'est-à-dire le passage du réseau d'un opérateur à un autre.

La mise en place d'un réseau GSM (en mode circuit) permettait principalement à un opérateur de proposer des services de type « voix » à ses clients en donnant l'accès à la mobilité tout en conservant un interfaçage avec le réseau fixe RTC (Réseau Téléphonique Commuté) existant. Délaissé au profit de nouvelles architectures du fait de sa faible capacité à transmettre des données numériques, il constitue néanmoins la base architecturale de tous ses successeurs.

Le standard GPRS (General Packet Radio Service) est une évolution de la norme GSM, ce qui lui vaut parfois l'appellation GSM++ (ou GMS 2+). Etant donné qu'il s'agit d'une norme de téléphonie de seconde génération permettant de faire la transition vers la troisième génération (3G), on parle généralement de 2.5G pour classifier le standard GPRS.

Le GPRS permet d'étendre l'architecture du standard GSM, afin d'autoriser le transfert de données par paquets, avec des débits théoriques maximums de l'ordre de 171,2 kbit/s (en pratique jusqu'à 114 kbit/s). Il vient ajouter un certain nombre de « modules » sur le réseau GSM sans changer le réseau existant.

Grâce au mode de transfert par paquets, les transmissions de données n'utilisent le réseau que lorsque c'est nécessaire. Le standard GPRS permet donc de facturer l'utilisateur au volume échangé plutôt qu'à la durée de connexion, ce qui signifie notamment qu'il peut rester connecté sans surcoût.

Aussi le standard GPRS utilise l'architecture du réseau GSM pour le transport de la voix, et propose d'accéder à des réseaux de données (notamment internet) utilisant le protocole IP ou le protocole X.25. Le réseau est donc constitué de routeurs IP.

Le GPRS permet de nouveaux usages que ne permettait pas la norme GSM, généralement catégorisés par les classes de services suivants :

· Services point à point (PTP), c'est-à-dire la capacité à se connecter en mode client-serveur à une machine d'un réseau IP,

· Services point à multipoint (PTMP), c'est-à-dire l'aptitude à envoyer un paquet à un groupe de destinataires (Multicast).

L'intégration du GPRS dans une architecture GSM nécessite l'adjonction de nouveaux noeuds réseau appelés GSN(GPRS Support Nodes) situés sur un réseau fédérateur (backbone) :

· le SGSN (Serving GPRS Support Node, soit en français Noeud de support GPRS de service), routeur permettant de gérer les coordonnées des terminaux de la zone et de réaliser l'interface de transit des paquets avec la passerelle GGSN.

· le GGSN (Gateway GPRS Support Node, soit en français Noeud de support GPRS passerelle), passerelle s'interfaçant avec les autres réseaux de données (internet). Le GGSN est notamment chargé de fournir une adresse IP aux terminaux mobiles pendant toute la durée de la connexion.

Le GPRS intègre la notion de Qualité de Service (noté QoS pour Quality of Service), c'est-à-dire la capacité à adapter le service aux besoins d'une application. Les critères de qualité de service sont les suivants : priorité, fiabilité, délai, débit.

Lorsque le mobile transmet des données vers un terminal fixe, les données sont transmises via le BSS (BTS + BSC) au SGSN qui envoie ensuite les données vers le GGSN qui les route vers le destinataire.

Le routage vers des terminaux (terminal mobile vers terminal mobile ou terminal fixe vers terminal mobile) utilise le principe d'encapsulation et des protocoles tunnels (partie grise sur la figure Figure 18 : Architecture du réseau GPRS). Les données reçues par le GGSN sont transmises au SGSN dont dépend le mobile destinataire.

Ainsi les données recueillies en protocole IP de l'extérieur via un routeur IP pourront être communiquées dans des paquets X25 par le principe du tunnel encapsulation - décapsulation. On parle de protocole PDP (Packet Data Protocol), l'encapsulation consiste ainsi à placer une unité de protocole A dans une unité de protocole B sans que ce dernier ne se préoccupe du format des données transportées.

Le GPRS peut être vu comme un réseau de données à part entière qui dispose d'un accès radio tout en réutilisant une partie du réseau GSM. Les débits fournis permettent d'envisager des applications comme la consultation de sites internet ou le transfert de fichiers en mode FTP (File Transfert Protocol).

Dans la première version du GPRS seul un service de transmission point à point (PTP - Point To Point) a été proposé. Une information envoyée par un terminal vers un terminal.

Les services points à multi-points (PTM- Point To Multi-point) - une information envoyée d'un fournisseur de contenus vers plusieurs terminaux - seront ensuite proposés à des communautés ou des zones géographiques. On parle de PTP Broadcast.

Le réseau GPRS permet de considérer le réseau GSM comme un réseau à transmission de données par paquets avec un accès radio. Le réseau GPRS est compatible avec des protocoles IP et X.25. Des routeurs spécialisés SGSN et GGSN sont introduits sur le réseau.

La transmission par paquet sur la voie radio permet d'économiser la ressource radio : un terminal est susceptible de recevoir ou d'émettre des données à tout moment sans qu'un canal radio soit monopolisé en permanence comme c'est le cas en réseau GSM.

La mise en place d'un tel réseau permet à un opérateur de proposer de nouveaux services de type Data avec un débit de données plus de 10 fois supérieur au débit maximum du GSM (114 Kbps contre 9,6 kbps).

Baptisé réseau 2,5G, le GPRS a été amélioré par un facteur quatre (4) par la norme EDGE (Enhanced Data Rates for Global Evolution), présentée pour l'occasion comme 2.75G devenant ainsi une étape vers les réseaux de données plus évolués nommés 3G.

Les spécifications IMT-2000 (International Mobile Telecommunications for the year 2000) de l'Union Internationale des Communications (UIT), définissent les caractéristiques de la 3G (troisième génération de téléphonie mobile). Ces caractéristiques sont les suivantes :

· une compatibilité des services mobiles de 3ème génération avec les réseaux de seconde génération,

La 3G propose d'atteindre des débits supérieurs à 144 kbit/s, ouvrant ainsi la porte à des usages multimédias tels que la transmission de vidéo, la visio-conférence ou l'accès à internet haut débit. Les réseaux 3G utilisent des bandes de fréquences différentes des réseaux précédents : 1885-2025 MHz et 2110-2200 MHz.

La principale norme 3G utilisée en Europe et en Afrique s'appelle UMTS (Universal Mobile Telecommunications System), utilisant un codage W-CDMA (Wideband Code Division Multiple Access). La technologie UMTS utilise la bande de fréquence de 5 MHz pour le transfert de la voix et de données avec des débits pouvant aller de 384 kbps à 2 Mbps.

La mise en place du réseau UMTS implique la mise en place de nouveaux éléments sur le réseau

Le Node B est une antenne. Répartis géographiquement sur l'ensemble du territoire, les Nodes B sont au réseau UMTS ce que les BTS sont au réseau GSM. Les Nodes B gèrent la couche physique de l'interface radio. Le Node B régit le codage du canal, l'entrelacement, l'adaptation du débit et l'étalement.

Les Node B communiquent directement avec le mobile sous l'interface dénommée Uu^6(*).

Le RNC est un contrôleur de Node B. le RNC est encore ici l'équivalent du BSC dans le réseau GSM. Le RNC contrôle et gère les ressources radio en utilisant le protocole RRC (Radio Ressource Control) pour définir les procédures de communication entre mobiles (par l'intermédiaire des Nodes B) et le réseau.

Le RNC s'interface avec le réseau pour les transmissions en mode paquet et en mode circuit.

· Le contrôle d'admission et d'allocation des codes pour les nouveaux liens radio (entrée d'un mobile dans la zone de cellules gérées...)

NB : L'ensemble des Node B et des RNC constitue l'équivalent de la sous architecture BSS vue précédemment en réseau GSM. En réseau UMTS, on parlera de sous architecture UTRAN^7(*).

Le réseau coeur de l'UMTS s'appuie sur les éléments de base des réseaux GSM et GPRS. Le réseau coeur est en charge de la commutation et du routage des communications (voix et données) vers les réseaux externes. Dans un premier temps le réseau UMTS devrait s'appuyer sur le réseau GPRS.

Le réseau coeur se décompose en deux parties : le domaine circuit et le domaine paquet.

Le domaine circuit permet de gérer les services temps réels dédiés aux conversations téléphoniques (vidéo-téléphonie, jeux vidéo, streaming^8(*), applications multimédia). Ces applications nécessitent un temps de transfert rapide. Le débit du mode domaine circuit est de 384kbps. L'infrastructure s'appuie sur les principaux éléments du réseau GSM : MSC/VLR (base de données existantes) et le GMSC^9(*) afin d'avoir une connexion directe vers le réseau externe.

Le domaine paquet permet de gérer les services non temps réels. Il s'agit principalement de la navigation sur l'Internet, de la gestion de jeux en réseaux et de l'accès ou l'utilisation des e-mails. Ces applications sont moins sensibles au temps de transfert. C'est la raison pour laquelle les données transitent en mode paquet. Le débit du domaine paquet est sept fois plus rapide que le mode circuit, environ 2Mbits/s. L'infrastructure s'appuie sur les principaux éléments du réseau GPRS : SGSN (base de données existantes en mode paquet GPRS, équivalent des MSC/VLR en réseau GSM) et le GGSN (équivalent du GMSC en réseau GSM) qui joue le rôle de commutateur vers le réseau Internet et les autres réseaux publics ou privés de transmission de données.

Le réseau UMTS permet à l'opérateur de proposer à ses abonnées des services innovants. Le GSM répond aux attentes en termes de communication de type voix et le réseau GPRS répond aux attentes en termes d'échanges de données en complément du réseau GSM. L'avènement des réseaux UMTS sonne l'ère du multimédia portable.

A terme le réseau coeur UMTS pourrait migrer vers une solution complète IP à condition d'apporter des solutions aux problèmes de l'IP en termes de service (QoS). Il y a fort à parier que les opérateurs migreront vers un réseau unique (domaine paquet et domaine circuit réunis) avec l'utilisation de plus en plus fréquente de la VOIP^10(*).

Le réseau UMTS est complémentaire aux réseaux GSM et GPRS. Le réseau GSM couvre les fonctionnalités nécessaires aux services de type voix en un mode circuit, le réseau GPRS apporte les premières fonctionnalités à la mise en place de services de type Data en mode paquets, et l'UMTS vient compléter ces deux réseaux par une offre de services Voix et Data complémentaires sur un mode paquet.

La mise en place d'un réseau UMTS va permettre à un opérateur de compléter son offre existante par l'apport de nouveaux services en mode paquet complétant ainsi les réseaux GSM et GPRS. Face à la convergence très forte entre la voix et la donnée, l'UMTS ou 3G semble être le réseau de communication du futur avec sa normalisation au niveau mondial et l'idée d'un accès aux technologies de l'information et de la communication depuis n'importe quel endroit couvert de la planète.

L'évolution du GSM vers l'UMTS est une évolution technologique poussée par une évolution - marché avec des demandes orientées service. Il existe deux approches des services :

· Les services « Telco centric » destinés à l'opérateur : ici un fournisseur apporte une solution permettant de réduire des frais de fonctionnement, de réaliser des économies d'échelle...). Ici le client du fournisseur de service est l'opérateur.

· Les services « end user centric » : des services ou des applications développés par l'opérateur et ses fournisseurs en vue de définir un service pour l'abonné (nouveau service, amélioration de la qualité réseau). Ici le client est l'abonné.

Dans ce type de services, plusieurs acteurs participent à la création de la valeur pour l'utilisateur final.

Un opérateur télécom est une entité administrative indépendante. Un opérateur, un MNO (Mobile Network Operator) gère un réseau, un PLMN (Public Land Mobile Network). L'opérateur est en charge de trois grandes missions :

· Il assure l'interconnexion avec les autres réseaux nationaux ou internationaux (on parle dans ce cas de roaming lorsqu'un abonné d'un pays A se rend dans un pays B)

La politique d'un opérateur télécoms consiste à trouver de nouvelles sources de revenus autres que le canal « Voix ». Les réseaux de troisième génération doivent permettre de générer de nouvelles sources de revenus sur de nouveaux business models^11(*) « Data ». Dans cette optique, l'opérateur peut proposer d'autres services.

Les services à valeur ajoutée sont fournis, en interne, par les opérateurs de téléphonie mobile eux-mêmes ou par un tiers fournisseur de SVA (FSAV ou VASP^12(*)), également connu sous le nom de fournisseur de contenu (CP^13(*)). Les VASPs sont généralement connectés à l'opérateur en utilisant des protocoles comme SMS peer-to-Peer Protocol (SMPP), soit en se connectant directement au centre de service de messages courts (SMSC) ou, de plus en plus, à une passerelle de messagerie qui permet à l'opérateur de mieux contrôler et de prendre en charge les contenus distribués sur son réseau.

Ils deviennent de plus en plus des éditeurs d'applications pour mobiles pour le compte des opérateurs.

Il est le dernier maillon de la chaine de valeur. Il est détenteur d'un terminal et est abonné à un opérateur pour le compte duquel il génère un ARPU^14(*) en utilisant ses services ou ceux proposés par les VASP.

· Communication : permettant d'entrer en communication au sens large (voix, SMS, WAP)

· SVA : services additionnels permettant d'accéder à de l'information ou des jeux

· M-commerce : services permettant un contact e-commerce avec le milieu bancaire et de faire des transactions financières.

· Service localisés : ensemble d'applications qui, à l'aide du mobile, permettent de localiser l'abonné pour l'assister et le surveiller

Le SVA (VAS en anglais) est un terme télécom qui désigne les services qui ne sont pas coeurs de métiers, par extension désigne tous les services qui ne sont pas des services de voix.

De manière conceptuelle, c'est un service additionnel qui permet de stimuler l'utilisation du téléphone et par conséquent permet à l'opérateur d'augmenter l'ARPU.

A ce titre le SMS dépasse largement, de par son utilisation, les autres technologies (WAP, MMS).

Au Sénégal, par exemple, 435 millions de SMS ont été échangés en 2007 selon l'ARTP^15(*). Cela est en grande partie dû à deux raisons :

Téléphonie mobile	déc.-06	mars-07	juin-07	sept.-07	déc.-07
Parc total	2 982 623	3 378 272	3 319 616	3 434 142	4 122 867
Croissance nette trimestrielle	341 512	395 649	-58 656	114 526	688 725
Croissance en %	12,93%	13,27%	-1,74%	3,45%	20,06%
Taux de pénétration	28,19%	31,93%	31,38%	32,46%	38,97%

Tableau 3 : Evolution du parc mobile au Sénégal entre décembre 2006 et décembre 2007

Figure 20 : Evolution trimestrielle du parc global de la téléphonie mobile

Sources des 3 dernières illustrations : ARTP - OBSERVATOIRE DE LA TELEPHONIE MOBILE, données chiffrées au 31 décembre 2007

Dans le monde, les acteurs historiques du web traditionnel ont investi le marché du mobile pour accompagner les premiers pas de l'internet mobile. On entend ainsi parler de portails mobiles tels que Yahoo Go, Google Mobile, MSN Mobile, AOL Mobile qui visent à apporter la meilleure expérience possible de l'Internet aux milliards de consommateurs mobiles dans le monde.

Des cybermarchands ont aussi commencé à se rapprocher des mobinautes^16(*) même si les usages commerciaux du téléphone tardent à décoller : le marché de la publicité sur mobile est aujourd'hui encore embryonnaire tandis que le marché du m-commerce reste limité aux biens digitaux à faible valeur monétaire (logos et sonneries principalement).

Pour booster l'internet mobile en général, et le m-commerce en particulier, 2SI compte mettre en place :

Il est à noter que la qualité de ces services, qui transportent de plus en plus de données, est fortement liée aux réseaux qui les supportent.

services	2G	2.5G	3G
Fichier E-mail (10Ko)	8 secondes	0.7 seconde	0.04 seconde
Page web (9Ko)	9 secondes	0.8 seconde	0.04 seconde
Fichier texte (40Ko)	33 secondes	3 secondes	0.2 seconde
Rapport (2Mo)	28 minutes	2 minutes	7 secondes
Clip vidéo (4Mo)	48 minutes	4 minutes	14 secondes

Tableau 4 : Les temps de réalisation des services suivant les types de réseau

Ce tableau montre la réalité de l'utilisation de quelques services. En vert les temps d'accès aux services jugés « convenables », en rouge, ceux qui sont « inconcevables ». L'accès rapide aux fichiers de l'ordre de dizaines de Mo ne peut se concevoir sans un réseau 3G.

Chapitre 4 : Spécifications détaillées de notre plateforme

Dans un contexte réseau favorable, avec une clientèle demandeuse, 2SI propose deux types de services dans sa plateforme :

Les terminaux mobiles stockent des données importantes telles que des contacts, des agendas ou bien des listes de tâches. Cependant ces données peuvent être perdues dès que le terminal est endommagé ou perdu. Les abonnés ont ainsi besoin de sauvegarder leurs données et de les récupérer au besoin.

SOS-PIN, du nom du service à développer par 2SI, permettra d'assurer la pérennité des données personnelles. Il permettra à un abonné de stocker ses données à partir de n'importe où sur le réseau et de les récupérer au besoin. Ce service nécessitera l'installation d'une application, sur le mobile du client, chargée de communiquer avec l'application installée sur le serveur de l'autre côté du réseau.

L'application cliente permet de lancer, au gré de l'utilisateur du mobile, le processus d'échange de données. Elle adopte différents comportements selon le mode d'échange entre le mobile et le serveur. Dans le cas d'une communication "client vers serveur" (sauvegarde), cette application est chargée de collecter, arranger et envoyer les données situées sur le terminal.

Dans le cas d'un échange "serveur vers client" (restauration), elle est chargée de récupérer les données envoyées par le serveur, de les comparer aux données existantes et de stocker les bonnes données en évitant toute redondance.

Elle est chargée de communiquer avec le client mobile. Selon les modes d'échanges, elle récupère les données envoyées par le mobile ou renvoie au client mobile ses données stockées auparavant. Elle est aussi chargée d'attribuer à chaque client un espace de stockage de ses données.

Au terme d'un échange de données entre le serveur et le client, la base de données cliente et l'espace de stockage réservé par le serveur à ce client sont identiques. Ce processus s'appelle la synchronisation.

Dans ce service, toutes les ressources seront localisées sur le réseau. Il n'est pas besoin d'installer une application sur le terminal mais ce dernier doit avoir une configuration minimale requise.

Dans un souci de faciliter l'accès à de grands spectacles ou à certains endroits au grand public, les téléphones mobiles peuvent jouer le rôle de porte-billet électronique en lieu et place du traditionnel billet en papier.

M-ticketing consiste alors en la dématérialisation des billets de spectacles, transport, etc.

Un ticket est un billet attestant un paiement et donnant droit à un service, à l'entrée dans un établissement ou à l'accès à un moyen de transport.

Dans ce qui suit, nous considérerons le cas où le ticket donne accès à un événement. Ces événements sont regroupés par type et il existe une ou plusieurs catégories de tickets donnant accès aux différents événements d'un même type, chaque événement définissant ses propres prix par catégorie.

La dématérialisation est la transformation d'un flux de documents, ainsi que les traitements qui lui sont appliqués, en flux et traitements numériques. Elle consiste à mettre en oeuvre des moyens électroniques pour effectuer des opérations de traitement, d'échange et de stockage d'informations sans support papier. Elle n'a aucun effet sur le contenu de ces informations qui restent ce qu'elles sont indépendamment de la forme que prend leur support.

En partant du constat que le portable accompagne son propriétaire partout, il peut jouer facilement le rôle de porte-billet électronique où les billets sont affichés à l'écran sous forme de code barres comme celui figurant sur la majorité des produits en vente dans le commerce.

Après une transaction effectuée à partir d'un mobile habilité ou sur Internet, le billet est envoyé sur le terminal du client sous la forme d'un SMS-image ou d'un MMS (selon les caractéristiques du portable de l'abonné).

En se débarrassant du support papier, ce service génère plus de confort pour le client. Celui-ci peut en effet effectuer sa commande jusqu'au dernier moment (contrairement à la vente à distance de billets papier qui nécessite de s'y prendre à l'avance). De plus, il facilite le contrôle d'accès : il suffit juste de faire passer l'écran du mobile devant un lecteur code barres.

Ce service, outre qu'il est accessible à partir du web, compte s'appuyer sur le modèle existant de vente de crédit de recharge où un détaillant (le mobile habilité cité ci-haut) initie la transaction.

NB : les numéros sur la figure indiquent l'ordre chronologique des actions effectuées dans ce service.

L'identification des modules nous permettra de dégager les tâches à faire, de les planifier et de faire les choix technologiques nécessaires à leur réalisation.

A partir de ce portail, un utilisateur pourra acheter autant de tickets qu'il le désire. Il devra renseigner les numéros de téléphone des bénéficiaires, les événements, et les catégories. Il devra en plus renseigner son numéro de carte bancaire pour le paiement. Ce portail propose, en outre, à ses visiteurs une vue globale sur l'ensemble des événements pris en compte.

Dans le cas de l'achat à partir du portail web, notre application devra communiquer avec un système de paiement en ligne qui se chargera d'autoriser la transaction.

Ce module permettra de générer, de manière sécurisée, les images (codes barres 1D^17(*)) qui représentent les tickets à partir de numéros reçus en entrée. Ces numéros seront aussi générés selon un algorithme précis.

Ce module permettra d'envoyer un SMS image ou MMS selon la compatibilité du terminal du bénéficiaire. Le MMSC de l'opérateur sera mis en contribution.

Le bénéficiaire fait passer son terminal sous un lecteur de code barres. Un dispositif léger récupère l'information (le numéro du ticket) et informe notre application que ce ticket vient d'être consommé.

Pour des raisons de mobilité et de performances, nous utilisons le Workabout Pro G2, un micro-ordinateur prenant en charge une large gamme de cartes et de modules d'extensions parmi lesquels des lecteurs de codes barres (voir image 3 ci dessous), des cartes SIM pour fonction de téléphonie, des extensions WIFI. Elle est basée sur une architecture (OS) Windows Embedded (Windows CE) ou Windows Mobile.

· Un espace pour l'administration globale du portail : c'est à ce niveau que sont gérés les événements (création, suivi, etc)

· Un espace d'administration restreinte à partir duquel un organisateur ne peut gérer que son événement

Lorsqu'un client désire acheter un ticket à partir d'un point de vente, le vendeur informe l'opérateur de la transaction et lui transmet toutes les informations nécessaires (événement, catégorie, numéro du destinataire) par USSD. L'opérateur, après avoir vérifié que le crédit du bénéficiaire est suffisant pour une telle transaction, informe notre application et lui transmet les paramètres.

L'USSD est un moyen de transmission d'information sur un réseau GSM, GPRS, UMTS. Il a été défini standard (standards ETSI, 3GPP [1] [2] [3]) à l'origine pour la commande de services supplémentaires spécifiques aux opérateurs. Il offre aujourd'hui en pratiques des possibilités de services beaucoup plus vastes (accès à des bouquets de services, consultation des comptes prépayés ou post payés...).

Il offre aussi une connexion orientée session, half-duplex et bi-directionnelle entre un terminal mobile et un serveur applicatif USSD. Les sessions peuvent être ouvertes à l'initiative du mobile par simple appel d'un code de service (i.e numéros courts avec des * et des #).

L'USSD utilise le canal de signalisation : il est peu gourmand en ressources réseaux et donc peu coûteux contrairement au SMS qui est du type store-and-forward et qui nécessite la présence d'un SMSC (SMS Center) dans le circuit de traitement. Il peut être assimilé à telnet alors que le SMS est assimilé au mail.

Cette technologie est entrain d'être largement acceptée comme le canal idéal de services tels que l'information par mobile, le commerce sur mobile et tout autre service qui nécessite une interaction entre le client et l'application. Comparé à l'IVR^18(*), l'USSD améliore quantitativement les temps de réponse : de 25 à 7 seconds^19(*).

Il est typiquement utilisé comme déclencheur (trigger) pour invoquer des services. C'est le cas des services de recharge de crédit ou de consultation de solde.

Chapitre 5 : Conception de la plateforme

Pour 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.

Objectif : A partir d'un terminal mobile, l'utilisateur pourra effectuer la sauvegarde de ses données personnelles dans un serveur distant.

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.

Cas d'utilisation	Description	Acteur	Relations entre cas
1. Choisir service de sauvegarde	L'utilisateur choisit le service de sauvegarde	utilisateur
2. Initialiser client	L'application cliente initie la synchronisation	client
3. Initialiser serveur	Le serveur est prêt à synchroniser	serveur
4. Sauvegarder données	Le client envoie les données de son répertoire	client	Inclut 2.
5. Envoyer accusé	Le serveur signifie au client que l'échange s'est bien déroulé	serveur	étend 3.
6. Notifier utilisateur	L'application cliente notifie l'utilisateur	client	étend 4.

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.

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é.

Objectifs : l'acheteur pourra réserver un ticket qui sera envoyé par MMS sur un mobile précisé

Acteurs	Description	Type
Acheteur	C'est le visiteur du portail qui effectue une transaction	secondaire
Client	C'est le terminal mobile qui recevra le ticket sous forme d'image	secondaire
Système de paiement (SP)	Il est chargé de contrôler le paiement	secondaire
Serveur MTicket (SM)	Il est chargé de générer un ticket et de l'envoyer au client	principal

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

Cas d'utilisation	Description	Relation
1. Choisir ticket	L'acheteur choisit le ticket qui lui convient
2. Traiter paiement	Le SP contrôle le paiement
3. Vérifier compatibilité terminal client	Le SM s'assure que le client peut recevoir un MMS
4. Générer ticket	Le SM génère un ticket récupérable par le client	Inclut 3.
5. Envoyer MMS	Le SM envoie le MMS au client	Inclut 4.

Troisième partie : Mise en place de la solution

Ø Le choix des outils et technologies d'implémentation : pour la réalisation de chaque tâche, on présente les différentes possibilités et on en retient une que l'on va utiliser ;

Ø L'implémentation de la plateforme : Ici nous présenterons dans les détails la réalisation des différentes tâches identifiées.

Chapitre 6 : Choix des outils et des technologies d'implémentation

Une plate-forme applicative se présente sous la forme d'une suite logicielle comprenant l'ensemble des briques nécessaires au déploiement d'une application client/serveur de haut niveau à savoir : une application ou plusieurs applications serveur accessibles - généralement en mode Web - depuis des postes de travail ou des terminaux Internet.

· Le serveur d'applications gère le noyau de l'application avec pour objectif central de répondre aux requêtes des utilisateurs s'y connectant.

· Le serveur de données stocke l'ensemble des données métier et techniques nécessaires au bon fonctionnement de l'application.

· L'infrastructure de portail a pour but d'orchestrer les droits d'utilisation de l'application et de gérer la personnalisation des données et des accès fonctionnels.

· Le serveur d'intégration prend en charge les éventuels flux de données ou composants à prendre en compte, en provenance d'autres serveurs d'applications ou systèmes.

Dans ce domaine, deux architectures sophistiquées mènent une rude bataille. Il s'agit de J2EE (pour Java 2 Enterprise Edition) et .Net. Cependant la combinaison Apache/Mysql/PHP, adossée à un système d'exploitation, brille aussi de mille feux.

Lancé par Sun en 1998, autour du langage Java, il s'articule autour d'une infrastructure standardisée, couvrant les principales couches d'une plate-forme applicative (serveur d'applications, infrastructure de portail et serveur d'intégration), ainsi que les liens avec la base de données (ou persistance). J2EE est aujourd'hui implémenté par les principaux éditeurs de serveurs d'applications du marché, parmi lesquels on compte IBM, Oracle et BEA.

J2EE est portable d'un système d'exploitation à l'autre. Un point fort qui, dès l'origine, a été mis en avant par Sun comme l'une des principales valeurs ajoutées de son infrastructure. Initialement, Java a d'ailleurs été élaboré pour répondre précisément à cet enjeu. Dans la même logique, J2EE facilite également le portage d'une application Java entre serveurs d'applications, pour peu que ces derniers répondent aux spécifications définies par Sun dans ce cadre.

Le modèle .Net (lire DotNet) a été lancé par Microsoft en 2001 en réponse à J2EE. Cette plate-forme, rebaptisée en 2003 Windows Server System, s'adosse à la manière de J2EE à une logique de développement et de déploiement de nouvelle génération (orientée objets). Son principal point fort : aussi structurante et riche fonctionnellement que son équivalent Java, elle n'en offrirait pas moins une approche de travail beaucoup plus simple. Basé sur C#, .Net offre un autre avantage de taille sur J2EE : son noyau permet d'exécuter des applications développées dans n'importe quel langage, à partir du moment où Microsoft a décidé de le supporter. C'est notamment le cas avec le Python ou encore le Cobol.

Cependant c'est une plateforme trop propriétaire et ne tourne que sous Windows.

PHP est un langage de scripts. Il est interprété, par conséquent il ne nécessite pas d'être compilé pour obtenir un objet, un exécutable avant d'être utilisable (comme en C par exemple).
PHP est un module supporté par le serveur web frontal Apache, le plus répandu dans le monde (plus de 70% des serveurs web), il est donc développé pour être facilement utilisable via ce serveur et s'interface très facilement à MySQL.

Suivant le système d'exploitation utilisé qui assure l'attribution des ressources aux autres composants de la plateforme, on parle de LAMP, WAMP, MAMP, SAMP respectivement pour Linux, Windows, Macintosh, Solaris.

Offrir davantage d'ouverture et de compatibilité entre systèmes informatiques est depuis longtemps un secteur en constante évolution.

L'avènement des technologies Internet n'a fait qu'étendre ce vieux concept à des applications distribuées au delà d'un réseau d'entreprise. Le secteur économique des TIC (Technologies de l'Information et de la Communication) est bien évidemment à l'écoute de ce genre de problématique car fournir des services informatiques intégrables directement, et de manière transparente, au sein de SI existants intéresse nécessairement des acteurs, existants ou futurs, de ce marché.

Dans l'absolu, l'interopérabilité consiste à utiliser conjointement des fonctionnalités d'applications basées sur des technologies différentes (J2EE, .NET, PHP, C++, etc.). Une des motivations peut provenir de la volonté de consommer depuis ses applications des services métier gérés par des partenaires externes (opérateurs, établissements bancaires, etc.). C'est un dialogue bilatéral entre deux systèmes.

Le véritable objectif est alors de permettre cette interopérabilité le plus simplement possible, en abstrayant à la fois aux utilisateurs finaux et aux développeurs la complexité et la diversité des environnements.

L'administration technique du SI ne doit cependant pas s'en trouver complexifiée outre mesure. Il est important que les équipes responsables de cette administration puissent facilement prendre le contrôle et gérer ces solutions.

Prenons l'exemple de notre application de MTicketing qui a besoin de communiquer avec le SI de l'opérateur et, par moment, avec les établissements bancaires.

Au delà de simples appels de fonctions sur des applications de ces différents SI, des besoins de sécurité (paiement en ligne), de gestion transactionnelle (réservation) ainsi que de transmission de données « brutes » (le code barre en image) doivent être gérés. Et tout cela de la manière la plus transparente possible et avec la plus grande facilité d'administration !

La bataille que se livre actuellement Sun et Microsoft au sujet des environnements de développement a un impact direct sur les plateformes embarquées proposées de part et d'autre. D'un coté, Sun propose Java 2 Micro Edition (J2ME) à travers son architecture J2SE, et de l'autre, Microsoft propose Smart Device Extensions (SDE) basé sur sa plate-forme .NET. Si jusqu'au début du millénaire, ce marché était essentiellement représenté par des acteurs très spécifiques de l'embarqué autour de multiples technologies propriétaires, il semble acquis aujourd'hui, à la lueur des évènements, que ces deux leaders mondiaux du logiciel que sont Microsoft et Sun seront à l'origine des prochaines générations de plateformes embarquées. Ce recentrage autour de Java et .NET ne sera pas sans effets. D'une part, l'utilisation de technologies standards et largement adoptées par l'industrie va tendre à réduire les risques d'enfermement technologiques et pérenniser les investissements. D'autre part, cela aura un impact indéniable en termes de réduction des coûts car les outils, les compétences et les architectures matérielles se résumeront à ces deux plateformes maîtrisées. Il va de soi que le mieux placé sur le terrain des outils de développement aura un avantage indéniable sur celui de la production.

A partir de ce constat, nous avons choisi de défricher les deux solutions prédominantes du moment. Dans un premier temps, nous nous attacherons à présenter les deux architectures concurrentes, puis nous porterons notre choix sur l'une d'elles que nous présenterons plus en détail.

La mise en place d'une plate-forme technique commune à tous les périphériques est une opération très délicate. Chaque appareil possède des spécificités qui obligent les applications à s'adapter à différentes caractéristiques d'affichage ou de pointage. Microsoft et Sun n'ont pas du tout la même approche concernant ce problème. Si J2ME s'attache à unifier par le biais d'APIs les différents types d'appareils, Microsoft préfère proposer un ensemble de briques logicielles dans le cadre de son système d'exploitation embarqué : Windows CE.

La liste suivante démontre la variété des terminaux ciblés par les deux plate-formes :

· Téléphone cellulaire, Smartphone (Nokia, Ericsson, Alcatel, Siemens, ...)

· Appareil d'imagerie numérique (Caméscope numérique, Appareils photo numérique, ...)

· Appareil automatique industriel (Robot dans une chaîne d'usinage, Affichage embarqué dans les automobiles,...)

Toute la difficulté de concevoir des technologies pour l'embarqué réside dans cette complexité inhérente à la diversité de l'offre. Nous verrons que cela aura un impact important sur la conception interne des environnements proposés de part et d'autre.

Java 2 Micro Edition ou Java ME ou Java Platform Micro Edition est l'édition de la plateforme Java à destination de l'électronique grand public. Cette architecture technique a donc pour but de fournir un socle de développement aux applications embarquées. L'intérêt étant de proposer toute la puissance d'un langage tel que Java associé aux services proposés par une version bridée du Framework J2SE : J2ME. Les terminaux n'ayant pas les mêmes capacités en termes de ressources que les ordinateurs de bureau classiques (mémoire, disque et puissance de calcul), la solution passe par la fourniture d'un environnement allégé afin de s'adapter aux différentes contraintes d'exécution. Cependant, comment faire en sorte d'intégrer la diversité de l'offre à un socle technique dont la cible n'est pas définie à priori ? La solution proposée par J2ME consiste à regrouper par catégories certaines familles de produits tout en proposant la possibilité d'implémenter des routines spécifiques à un terminal donné. L'architecture J2ME se découpe donc en plusieurs couches :

1. Les profils : Ils permettent à une certaine catégorie de terminaux d'utiliser des caractéristiques communes telles que la gestion de l'affichage, des évènements d'entrées/sorties (pointage, clavier, ...) ou des mécanismes de persistance (Base de données légère intégrée). Ces profils sont soumis à spécifications suivant le principe du JCP (Java Community Process)

2. Les configurations : Elles définissent une plateforme minimale en termes de services concernant un ou plusieurs profils donnés.

3. Les machines virtuelles : En fonction de la cible, la machine virtuelle pourra être allégée afin de consommer plus ou moins de ressources

4. Le système d'exploitation : L'environnement doit s'adapter au système d'exploitation existant (Windows CE, Palm Os, SavaJe, ...)

Cette architecture en couches a pour but de factoriser pour des familles de produits données un ensemble d'APIs permettant à une application de s'exécuter sur plusieurs terminaux sans modification de code.

Une configuration est un environnement d'exécution Java complet constitué de trois éléments :

Pour pouvoir utiliser une configuration sur une machine donnée, elle doit remplir certaines conditions minimales définies dans les spécifications officielles. Bien qu'une configuration ne fournisse pas un environnement Java complet, l'ensemble des classes du noyau est normalement très petit et doit être enrichi d'autres classes supplémentaires fournies par les profils de J2ME ou grâce à l'implémenteur de configuration. En particulier, les configurations ne définissent aucune classe destinée à l'interface utilisateur.

CLDC signifie Connected Limited Device Configuration. Ce qui peut être traduit par configuration limitée pour appareils connectés.

Cette configuration s'adresse aux terminaux légers tels que les téléphones mobiles ou les assistants personnels. Ces périphériques étant limités en termes de ressources, l'environnement classique ne permet pas de respecter les contraintes d'occupation mémoire liées à ces appareils. J2ME définit donc un ensemble d'API spécifiques à CLDC et destinées à utiliser les particularités de chaque terminal d'une même famille (profil). La liste suivante résume l'ensemble de ses caractéristiques :

· Minimum de 160Ko à 512Ko de RAM, processeur 16 ou 32 bits, vitesse 16Mhz ou plus

Définie par un sous-ensemble de classes Java s'exécutant dans la KVM (KiloByte Virtual Machine), la CLDC s'inscrit donc dans une logique d'économie de ressources avec une KVM de 40 à 80 Ko s'exécutant 30 à 80% moins vite qu'une JVM normale. Il n'y a aucun compilateur Just-In-Time^20(*) ni même de prise en charge des nombres flottants. La KVM omet d'autres caractéristiques importantes telles que la finalisation. Cependant l'assortiment de classes exécutables du noyau ne représente qu'une toute petite fraction des classes du noyau de J2SE - classes de base des paquetages java.lang, java.io et java.util - accompagnées de quelques classes supplémentaires issues du nouveau paquetage javax.microedition.io. Quant au Multi-threading et au Ramasse miettes, ils demeurent supportés.

La CLDC n'intègre pas, non plus, la gestion des interfaces graphiques, la persistance ou les particularités de chaque terminal. Ces aspects ne sont pas de sa responsabilité. La matrice suivante résume les packages et classes présents dans cette couche :

Le package javax.microedition.io fait partie des briques non incluses dans J2SE tel qu'illustré dans la figure ci-après. Il gère les connexions distantes ou entrées/sorties réseau.

CDC signifie Connected Device Configuration. Ce qui peut être traduit par configuration pour dispositifs connectés. Elle spécifie un environnement pour des terminaux connectés de forte capacité tels que les téléphones à écran, la télévision numérique, etc.

Les caractéristiques de l'environnement matériel proposées par la configuration CDC sont :

· Support des spécifications complètes de la machine virtuelle Java optimisée, compacte et nommée pour l'occasion CVM (machine virtuelle C)

Cette configuration s'inscrit donc dans le cadre d'une architecture Java presque complète. C'est la raison pour laquelle elle requière plus de mémoire que la CLDC et un processeur plus rapide. La CDC est en fait un sur-ensemble de la CLDC.

Un profil ajoute à une configuration des classes spécifiques d'un domaine afin de combler l'absence d'une fonctionnalité et pour supporter les utilisations spécifiques d'un dispositif. Par exemple, la plupart des profils définissent des classes d'interfaces utilisateurs qui permettent de construire des applications interactives.

Pour pouvoir utiliser un profil, la machine doit satisfaire à toutes les exigences minimales de la configuration sous-jacente ainsi qu'à toutes les exigences rendues obligatoires par les spécifications officielles du profil qui se surajoutent.

Il existe plusieurs profils qui en sont à des stades de développement variables. Le Mobile Information Device Profile (MIDP = profil pour dispositifs informatiques mobiles), premier profil publié, est basé sur la CLDC et conçu pour les applications tournant sur téléphones mobiles et les bips interactifs disposant d'un petit écran, d'une connexion HTTP sans fil et d'une mémoire limitée. Un autre profil plus évolué basé sur la CLDC, le Personal Digital Assistant Profile (PDAP = profil pour assistant numérique personnel), prolonge le MIDP en lui ajoutant de nouvelles classes et caractéristiques permettant de couvrir la gamme des appareils de poche plus puissants. En ce qui concerne les profils de type CDC, le Foundation Profile (FP = profil fondamental) prolonge la CDC en lui ajoutant des classes de J2SE, le Personal Basis Profile (PBP = profil personnel de base) prolonge le FP grâce à l'ajout de classes peu encombrantes d'interfaces utilisateurs dérivées de l'Abstract Window Toolkit (AWT = outil qui permet de générer les fenêtres de dialogue de l'interface utilisateur) et d'un nouveau modèle d'application, et le Personal Profile prolonge le PBP avec le support d'applets et des classes d'interfaces utilisateurs plus encombrantes.

Le Mobile Information Device Profile (MIDP) définit un environnement d'exécution pour une classe d'appareils référencés sous le nom d'appareils mobiles d'informations (MID = mobile information devices). Cela correspond aux appareils dotés des caractéristiques minimales suivantes :

· Un écran numérique adressable d'au moins 96 pixels de largeur sur 56 pixels de hauteur, qu'il soit monochrome ou couleur.

Il contient des méthodes permettant de gérer l'affichage, la saisie utilisateur et la gestion de la persistance (base de données). Il existe aujourd'hui deux implémentations majeures de profils MIDP : l'une, plus spécifique, destinée aux Assistants de type Palm Pilot (PalmOs) et l'autre, totalement générique, proposée par Sun comme implémentation de référence (RI).

L'API lcdui est chargée de gérer l'ensemble des contrôles graphiques proposés par ce profil. Quant à la gestion des événements, elle suit le modèle des listeners du J2SE avec un CommandListener appelé en cas d'activation d'un contrôle. Pour finir, rms fournit les routines nécessaires à la prise en charge d'une zone physique de stockage.

Toute application MIDP est appelée MIDlet et doit dériver de la classe javax.microedition.midlet. Midlet.

Pour bien saisir leur mode de fonctionnement, il suffit de prendre comme analogie les Applets ou les Servlets. Le cycle de vie d'une Applet est géré par un conteneur, en l'occurrence le Navigateur Web, dont le rôle est d'interagir avec celle-ci sous la forme de méthodes de notifications prédéfinies (init(),paint(),destroyed(),...). Une servlet possède les mêmes caractéristiques qu'une Applet excepté le fait que le conteneur est un moteur de servlet (Tomcat, WebSphere, WebLogic, ...). Quant aux Midlets, ils représentent le pendant des Applets et des Servlets pour J2ME avec comme conteneur le téléphone mobile ou l'assistant personnel. Ainsi, en cas de mise à jour d'une application embarquée, un simple téléchargement de code Midlet est nécessaire à partir d'un quelconque serveur. De cette manière, un programme développé pour un profil donné est en mesure de s'exécuter sur tous les périphériques correspondant à cette famille. C'est aussi une manière de découpler le socle technique des applicatifs puisque le seul lien existant entre les logiciels embarqués et le terminal est l'API J2ME.

Une MIDlet connaît trois états dans son cycle de vie : en pause, active et détruite. Une fois créée par le système d'exploitation du téléphone, son état devient "en pause". Puis le système invoque la méthode startApp() qui change l'état en actif. Le retour au premier état a lieu lors de l'invocation de la méthode pauseApp(). Enfin, à tout moment l'exécution de la méthode destroyApp() conduit à l'état détruit. Nous constatons ainsi que la méthode startApp() peut se voir appelée plusieurs fois au cours du cycle de vie de l'application. Le constructeur de la MIDlet fera donc office de méthode main() pour toutes les tâches ne devant s'opérer qu'une seule fois.

A travers le temps, l'approche de Microsoft concernant le monde de l'embarqué a considérablement évolué. De Microsoft Embedded Visual Tools (eVB et C++), nous sommes passé à la plate-forme .NET et les différents langages qui l'accompagnent (C#, VB.NET, ...). Même s'il est vrai que l'engouement autour de cet univers des terminaux légers est allé croissant dès lors que les PDA et autres téléphones mobiles ont fait leur apparition, il n'en demeure pas moins que ce segment de marché a toujours été délaissé par le géant éditeur de logiciels. Aujourd'hui, l'offre de Microsoft est essentiellement basée sur son système d'exploitation embarqué : Windows CE.

Microsoft Embedded propose une approche plus orientée « système » de l'embarqué. Un constructeur désireux d'intégrer un environnement Windows dans un terminal donné, devra extraire les briques logicielles d'une version standard en fonction des caractéristiques du récepteur. Par exemple, dans le cas d'un périphérique sans fil, les composants embedded « wireless » accompagnés des drivers adéquats seront proposés à l'intégrateur. Lorsque le terminal nécessite une base de données embarquée, il suffira de générer une image du Système d'exploitation prenant en compte cette contrainte. Bref, Microsoft propose une panoplie de composants systèmes en tout genre et adaptés à tout type de besoin, charge ensuite à l'intégrateur de définir sa propre configuration. Cette approche comparée à Java est donc sensiblement différente.

Avec l'avènement du Framework .NET, la partie embarquée de l'offre de Microsoft a subi quelques évolutions majeures. Ainsi, le .NET Compact Framework (.NET CF) a fait son apparition au sein de l'architecture avec une philosophie proche de J2ME pour Java : Un ensemble d'API allégés permettant de répondre aux exigences des périphériques en termes de ressources. Mais .NET CF se destine aux plateformes Windows CE.

J2ME et Microsoft embedded Architecture ont une approche totalement différente dans leur manière d'aborder le développement embarqué. Si Java privilégie l'aspect Multi-périphériques et Multi-OS, Microsoft préfère concentrer ses efforts sur Windows CE, son système d'exploitation maison.

Malgré tous ces efforts, force est de constater que la technologie Microsoft ne parvient pas à rivaliser avec J2ME, ce dernier conservant de loin la première place en termes de taux de pénétration sur le terrain des logiciels mobiles. La plupart des grands constructeurs de téléphones portables au premier rang desquels figure Nokia demeurent en effet fidèle à l'infrastructure de Sun. Principal point fort de J2ME : sa portabilité. Une caractéristique qui le rend des plus attractifs pour les fournisseurs de services embarqués, qui cherchent à rendre leurs applications indépendantes des machines sous-jacentes.

De plus, il est à noter qu'il existe des machines virtuelles Java permettant d'exécuter une application J2ME sur Windows CE.

Une source de données est une installation de stockage des données. Elle peut être aussi sophistiquée qu'une base de données complexe, un annuaire ou un entrepôt de données pour une grande entreprise ou aussi simple qu'un fichier avec des lignes ou des colonnes. Une source de données peut être localisée sur un serveur distant ou bien disponible en local sur une machine de bureau.

Une base de données (son abréviation est BD, en anglais DB, database) est une entité dans laquelle il est possible de stocker des données de façon structurée et avec le moins de redondance possible. Ces données doivent pouvoir être utilisées par des programmes, par des utilisateurs différents.

Afin de pouvoir contrôler les données ainsi que les utilisateurs, le besoin d'un système de gestion s'est vite fait ressentir. La gestion de la base de données se fait grâce à un système appelé SGBD (système de gestion de bases de données) ou en anglais DBMS (Database management system). Le SGBD est un ensemble de services (applications logicielles) permettant de gérer les bases de données, c'est-à-dire :

· manipuler les données présentes dans la base de données (insertion, suppression, modification)

Les systèmes qui emploient le modèle relationnel pour contrôler la base de données sont nommés SGBDR (système de gestion de base de données relationnel).

De manière basique, tous les SGBD disponibles sur le marché intègrent ces fonctionnalités. D'autres raisons présideront alors au choix de l'un ou de l'autre parmi eux.

Disponible sou licence GPL sous Linux, Windows, MacOSX, Unix, BSD, MySQL en est à sa version 5.0.15 (beta 5.1). Ses principaux avantages sont :

C'est un SGBDR fonctionnant sur des systèmes de type UNIX et sur Windows. Ses avantages sont :

· Supporte la majorité du standard SQL-92 et possède en plus un certain nombre d'extensions (Java, Ruby, PL-SQL).

· Très riche fonctionnellement, notions d'héritage de tables, multitude de modules

La synchronisation offre la possibilité à un terminal de se connecter à un réseau afin de mettre à jour à la fois l'information de l'appareil et l'information du réseau pour que les deux soient identiques et à jour.

Devant la prolifération d'appareils mobiles et de protocoles propriétaires ainsi que la demande croissante d'accès à de l'information en situation de mobilité, les sociétés leader sur le domaine ont compris l'intérêt de créer un langage standard et universel décrivant les actions de synchronisation entre les terminaux et les applications. Elles ont formé un consortium pour sponsoriser cette initiative et pour créer ce langage.

Actuellement, le consortium SyncML a été adopté et incorporé à l'Open Mobile Alliance, un regroupement de plus de 300 sociétés qui supporte plusieurs projets collaboratifs portant sur les technologies et les protocoles.

SyncML ou Synchronization Markup Language est le protocole standard, basé sur XML, de synchronisation de données au travers d'une multitude de réseaux, de plates-formes et de terminaux. SyncML a été démarré en tant qu'initiative en 2000 par de grandes sociétés comme Ericsson, IBM, Palm Inc., Lotus, Matsushita Ltd. (Panasonic), Motorola, Nokia, Openwave, Starfish Software, Psion et Symbian. Leur but était la création d'un langage universel à partir de la myriade de protocoles de synchronisation propriétaires utilisés par les appareils mobiles et de fournir un ensemble complet de fonctionnalités de synchronisation pour les futurs terminaux. Le consortium a sorti la version 1.0 en décembre 2000. Ils ont développé de nouvelles fonctionnalités et résolu les problèmes découverts avec cette version, finalisant le protocole avec la version 1.1 en février 2002.

· Serveur - un système distant communiquant avec la base de données du système ou de l'application.

· Modifications - les données dans les champs d'une base de données qui sont modifiées.

· Synchronisation - le client et le serveur échangent des messages SyncML avec des commandes.

· Package - Balises XML conformes à la DTD de SyncML décrivant les requêtes ou actions qui doivent être effectuées par un client ou un serveur SyncML. Un package est un ensemble d'actions à effectuer.

· Message - La plus petite unité de balise SyncML. Les grands packages sont découpés en messages séparés.

· Mapping - Utilisation d'un identifiant intermédiaire pour lier deux informations. Exemple: Disons que 'vert' c'est '5', et '5' c'est bien. Qu'est-ce qui est bien ? Si vous répondez 'vert', vous êtes tombé juste. vous avez réalisé un mapping !

Un message est un ensemble de commandes SyncML transmises (en une seule fois) vers le client ou le serveur. La taille maximale d'un message est définie par la Meta données MaxMessageSize. Si un message à transmettre dépasse cette taille on le découpe en plusieurs messages. On parle alors de Multiple Message in Package. Un package correspond à un ensemble de messages pour effectuer une des étapes de la synchronisation. Les packages sont les suivants: pkg1 = initialisation du client (authentification, échange des devinf, des informations sur les bases à synchroniser), pkg2 = initialisation du serveur, pkg3 = modification côté client, pkg4 = modification côté serveur, pkg5 = mis à jour des données et statuts, pkg6 = mapping des ids client et serveur.

SyncML est basé sur XML mais supporte obligatoirement un protocole de transport, par exemple HTTP, OBEX^21(*) ou WSP^22(*). Mais SyncML ne change pas quelque soit le protocole de transport. Une session SyncML est constituée de 4 phases :

1. La phase d'alerte du serveur, qui est optionnelle et peut être considérée comme une phase de pré-initialisation. Son principal objectif est de permettre au serveur d'alerter le client sur une probable session à démarrer.

2. L'initialisation de la synchronisation qui est un passage obligatoire pour le client et le serveur avant d'entamer une synchronisation. La première étape est que le client et serveur parlent le même langage, en s'échangeant l'un et l'autres leurs capacités (définies par le matériel, comme la quantité de mémoire, et le protocole définit par la DTD). La seconde étape est l'identification des bases de données à synchroniser. Ensuite, les deux doivent décider du type de synchronisation. La troisième et dernière partie est l'authentification. Une fois que cette étape à été complétée avec succès, la synchronisation à proprement parler peut commencer.

3. L'échange de données : normalement le client commence par envoyer ses modifications. Le serveur les reçoit, détecte et résout les conflits avant d'envoyer ses modifications.

4. La phase de finalisation dans laquelle s'effectuent le mapping, la mise à jour des ancres et l'envoi d'accusé de réception.

Le client s'identifie puis se met d'accord avec le serveur sur les principes d'échanges.

L'adressage est réalisé au travers des balises <Source> et <DocURI>. Un serveur aura une URI du genre http://www.2si.syncml.com/sync et le terminal mobile client aura un numéro d'identification IMEI comme ceci 354101000208403.

SyncML est basé sur l'idée que les clients et les serveurs peuvent avoir leur propre méthode pour faire correspondre les informations dans leur base de données. Aussi, les clients et les serveurs doivent avoir leur propre ensemble d'identifiants uniques.

Par gain de place, certains terminaux mobiles ne peuvent accepter, en effet, des id trop longs, ils vont alors définir leur propres id, et envoyer au serveur le mapping à effectuer à l'aide de la balise <Map>. De cette manière, le mobile ne stocke que l'id qu'il a choisi (généralement assez court) et le serveur, lui, stocke les deux, ce qui lui permet de s'adresser au mobile avec l'id que le mobile connait. Le serveur conserve l'ensemble des id indéfiniment.

Dans les futurs échanges, le mobile utilisera seulement l'id qu'il connait, et le serveur se chargera d'effectuer les mappings correspondants.

· Les identifiants locaux uniques (LUID - Locally Unique Identifiers) sont des nombres assignés par le client à une donnée dans la base de données locale (comme un champ ou une ligne). Ce sont des nombres non réutilisables assignés à ces objets par le client SyncML.

· Les identifiants globaux uniques (GUID - Globally Unique Identifiers) sont des nombres assignés à une donnée utilisés dans une base de données distante. Cet identifiant est assigné par le serveur.

Le serveur va créer une table de correspondance pour lier les LUID et GUID ensemble.

Les change logs sont une manière pour un dispositif (client ou serveur) de déterminer la liste des modifications dans la base depuis la dernière synchronisation

Les ancres servent à savoir si la dernière synchronisation s'est bien passée. Au début de session, le client envoie ses ancres (last et next). Le serveur stocke la next du client. A la fin de la session (s'il n'y pas eu d'interruption), le client met à jour ses ancres (last = next et il incrémente next). Lors de la prochaine session, le client envoie son next et last. Le serveur vérifie que le last du client vaut le next qu'il a stocké précédemment. Si c'est le cas, c'est OK, on continue. Sinon ça ne va pas du tout et le serveur peut forcer une slow sync.

Dans sa version 1.1, le langage SyncML définit 7 types de synchronisation. La section ci-dessous définit ces différents types:

1. Two-way Sync (Synchronisation bi-directionnelle) - Le client et le serveur s'échangent des informations relatives aux données modifiées. Le client transmet les modifications en premier.

2. Slow sync (Synchronisation lente) - Le client renvoie l'intégralité de ses données. Le serveur calcule le delta (avec les siennes) et le renvoie au client. Ce type de synchronisation est généralement utilisé lors d'une première synchro, lors d'une interruption, ou lorsque l'une des deux parties le demande.

3. One-way sync, client only (Synchronisation uni-directionnelle, Client uniquement) - Le client transmet ses modifications. Le serveur les accepte puis met à jour les données sans transmettre en retour ses modifications.

4. Refresh sync from client (Synchronisation de mise à jour avec les donnés du client) - Le client transmet sa base de données entièrement au serveur. Le serveur remplace la base de données cible par celle transmise par le client.

5. One-way sync, server only (Synchronisation uni-directionnelle, Serveur uniquement) - Le serveur transmet ses modifications au client. celui ci les accepte puis met à jour ses données locales sans transmettre en retour ses modifications.

6. Refresh sync from server (Synchronisation de mise à jour avec les donnée du serveur) - Le serveur transmet l'intégralité des informations de sa base de données. La base de données du client est entièrement remplacée.

7. Server alerted sync - Le serveur télé-commande au client d'initier un des modes de synchronisation présentés ci-dessus. De cette façon, le client est contrôlé à distance par le serveur.

Comme SOAP, il y a deux parties dans un message SyncML, un en-tête <SyncHdr> et un corps <SyncBody>. L'en-tête contient des méta-informations sur la requête comme la base de données cible <Target> et la base de données source <Source>, les informations d'authentification <Cred>, l'identifiant de session <SessionID>, l'identifiant du message <MsgID>, et la déclaration de la version de SyncML <VerDTD>. Le corps contient les commandes SyncML (les statuts des commandes du message précédent, et toutes les autres commandes prévues par SyncML).

Notez que les lignes {1} et {18} débutent le fichier SyncML par la balise racine. Ensuite, le SyncHdr est défini par les lignes {2} et {8}. Il contient :

- les lignes {3,4} qui définissent des informations concernant la version de SyncML utilisée,

- la ligne {5} définit l'identifiant de session (sessionID) qui permet d'identifier de façon unique le dialogue qui est en cours entre le client et le serveur,

- la ligne {6} représente l'identifiant du message (MsgID) qui permet d'identifier de façon unique cet ensemble de requêtes (toutes ces balises) qui vont être exécutées par l'application réceptrice.

- la ligne {7}, on trouve la balise Cred (demande d'authentification, non détaillée ici) qui fait également partie de l'entête.

Le SyncBody (Corps du message) commence à la ligne {9}. Dans cette partie du message SyncML, on trouve :

- et les actions demandées comme la synchronisation elle-même entre les lignes {11,16}.

Aux lignes {14,15}, on peut voir les commandes Add et Replace qui commandent respectivement l'ajout et le remplacement de données dans la base de donnée cible.

Convaincus de l'utilité de pouvoir disposer, au besoin, de données à jour sur son mobile, plusieurs éditeurs de logiciels se sont lancés dans la production d'une panacée : un serveur de synchronisation où l'information sur les mobiles serait stockée et centralisée.

On distingue deux grandes catégories de sociétés positionnées sur ce segment : les pure players^23(*) d'une part, les éditeurs généralistes d'autre part. Présents sur le marché depuis quelques années déjà, les premiers proposent des solutions généralement basées sur des technologies propriétaires et principalement articulées autour d'environnements de développement et d'exécution Java. Les éditeurs généralistes sont les derniers à explorer ce domaine.

Dans le monde de l'open source, un produit a fait le vide derrière lui : il s'agit de Funambol. Ce serveur est l'implémentation standard, de facto, de l'OMA. Il fournit, en plus du moteur de synchronisation, des API en C++ ou J2ME, pour le développement d'applications clientes. Ces API cachent au développeur toute la complexité de SyncML.

Funambol DS (Data Synchronisation) est contenu dans Tomcat et gère la communication http, la manipulation des sessions, l'échange de données avec le client et beaucoup d'autres fonctionnalités. Son architecture est construite autour du sync engine (moteur de synchronisation). Il transforme les messages SyncML reçus des clients et construit les messages destinés aux clients en guise de réponse. Le moteur de synchronisation permet au développeur de se focaliser sur la source de données à synchroniser avec l'application mobile.

La figure ci-dessus montre l'architecture du serveur Funambol composé de six éléments principaux:

1. L'adaptateur de synchronisation (sync adaptator ou transport mapper) qui reçoit les messages de SyncML HTTP et les convertit en une représentation interne qui sera envoyée avec HTTP.

2. L'input pipeline manager effectue un traitement supplémentaire du message SyncML entrant. En général il vérifie si la représentation interne est correcte pour être traitée par le moteur de synchronisation

3. L'output pipeline manager est similaire au précédent. Ses traitements se font sur les messages sortants

4. Le moteur de synchronisation est le coeur de Funambol. Il fournit la fonctionnalité applicative pour le protocole SyncML

5. Le moteur a accès à une source persistante dans laquelle il stocke les informations qu'il tient entre les sessions sur l'état de synchronisation des périphériques.

6. La source de synchronisation (sync source) est utilisée pour accéder à la source de données à laquelle un appareil mobile synchronise ses données.

Une application cliente interagit principalement avec deux entités de l'API: le SyncManager et le SyncSource. Le SyncManager est le composant qui gère toute la communication. Il cache la complexité des processus de synchronisation en fournissant une interface simple à l'application cliente. Le SyncSource représente la collection d'objets stockés dans le répertoire local. Il contient la logique métier du client pour découvrir les éléments à envoyer au serveur et pour stocker ceux obtenus à partir du serveur. Le client alimente le SyncSource avec les éléments changés du côté client, tandis que le SyncManager l'alimente avec les données reçues du serveur.

Pour chacun de nos deux services, nous aurons à faire des choix technologiques sur les différents segments de sa réalisation. Le service formant un tout, malgré son découpage en modules, un choix sur un segment peut influer sur le choix dans la réalisation d'un autre module.

Ainsi dans le cas du service de sauvegarde, le choix du serveur Funambol, basé sur le critère de l'open source et la fourniture d'APIs, a conditionné l'adoption du J2ME, du reste plus portable que SDE, comme technologie de développement de l'application cliente. De plus la disponibilité d'un connecteur à une base de données MySQL ou un annuaire LDAP fait sortir ces deux sources du lot. Cependant l'objectif même de la synchronisation, qui consiste à mettre à jour à chaque transaction le client et le serveur, joue en défaveur de LDAP prévu pour être plus sollicité en lecture qu'en écriture.

Le standard SyncML, supporté par HTTP, sera adopté comme langage de synchronisation car les APIs fournis par le serveur de synchronisation cachent, derrière leur utilisation, la manipulation complexe de ce langage.

Pour le service de billetterie dématérialisée, une plateforme LAMP est utilisée pour le serveur MTicket. Son caractère totalement open source, la quantité des données manipulées, ainsi que les accès web à réaliser justifient ce choix.

Cependant nous mettrons en oeuvre les principes d'interopérabilité pour des raisons de sécurité (la génération d'un ticket par un code php rendrait cette opération visible à partir d'un navigateur) et pour assurer la communication sécurisée avec les tiers, étant donné que la réalisation de certains modules (tels que l'envoi du ticket image, le traitement d'un message USSD) est dévolue à des acteurs externes. Java sera alors utilisé pour réaliser certaines de ces tâches.

Le process de validation sera quand à lui implémenté avec la plateforme .NET CF étant donné que le Workabout Pro G2 tourne sous Windows CE.

Chapitre 7 : Implémentation de la solution

Il s'agit en définitive, d'une part d'écrire une midlet capable de synchroniser avec le serveur installé en utilisant le SDK24(*) Funambol JavaME (entendre par là l'API SyncML cité supra), et d'autre part connecter le serveur à une base de données MySQL.

Ant est un projet open source de la fondation Apache écrit en Java qui vise le développement d'un logiciel d'automatisation des opérations répétitives tout au long du cycle de développement logiciel, à l'instar des logiciels Make.

Antenna fournit un de jeu de tâches Ant adéquates pour le développement d'applications destinées au MIDP. Antenna permet de compiler, prévérifier, packager et exécuter les applications MIDP.

· L'API Common qui vient en appoint pour l'exécution de certaines tâches telles la sérialisation. Il est disponible en téléchargement ici

SyncManager : c'est la classe principale qui contrôle le process de synchronisation et fait appel aux méthodes de la classe SyncSource

SyncConfig : classe utilisée pour instancier le SyncManager avec la configuration du client (URL,login, mot de passe, etc)

Implémentation de SyncSource : c'est l'implémentation de l'interface SyncSource qui est le lien entre le moteur de synchronisation (du côté du serveur) et le client. C'est la source des données du client à synchroniser.

SyncItem : représente l'objet échangé entre le SyncSource et le moteur de synchronisation, il peut transporter n'importe quel type d'information.

C'est l'interface entre le client et le moteur de synchronisation. En implémentant cette méthode de la manière la plus convenable pour accéder à la source de données cliente, nous pouvons synchroniser tout type de données à partir du mobile.

Nous pouvons implémenter cette interface directement ou bien nous pouvons étendre la classe abstraite BaseSyncSource , où une partie du travail est déjà réalisée. Les méthodes abstraites à implémenter sont les initXXXitems() pour initialiser les tableaux d'éléments à synchroniser (SyncItem), selon le mode de synchronisation, où XXX peut signifier :

all : il s'agit, dans ce cas, de tous les éléments stockés dans la base de données cliente. Il est utilisé dans le cas d'un slow sync ou d'un refresh from client

new : c'est pour récupérer le tableau des éléments ajoutés chez le client depuis la dernière synchronisation

upd : c'est le tableau des éléments modifiés depuis la dernière synchronisation

del : c'est le tableau des éléments supprimés de la base cliente depuis la dernière synchronisation

Pour gagner de la place en mémoire, il est important que ces tableaux ne contiennent que des informations sur les éléments, sans leur contenu qui pourra être récupéré par un appel à la méthode getItemContent(). Cette méthode est appelée pour chaque élément à synchroniser.

Une instance de SyncManager doit être créée avant d'entamer n'importe quelle synchronisation. Un SyncManager propose un constructeur recevant un SyncConfig en paramètre, qui doit être rempli lors de l'appel avec l'URL, un login et un mot de passe. Les autres informations peuvent être optionnelles.

Le SyncConfig contient aussi la classe DeviceConfig, un simple conteneur d'informations relatives à l'appareil telles que le manufacturier, etc.

Voici, sous forme de diagramme de classe, les relations entre les principales classes de l'API :

Une fois que nous avons instancié le SyncManager, nous pouvons démarrer la synchronisation par la méthode sync en passant le SyncSource en paramètre. La synchronisation sera lancée avec le mode de synchronisation stocké dans le SourceConfig .

En JavaME, nous exécuterons la synchronisation dans un thread séparément. L'implémentation minimale de la méthode run est la suivante :

Dans ce thread MySyncSource représente l'implémentation de notre SyncSource.

installer la version bundle du serveur de synchronisation disponible en téléchargement ici (http://funambol.com/opensource/download.php?file_id=funambol-6.5.14.exe). Le répertoire d'installation sera nommé FUNAMBOL_HOME. Par défaut ce sera C:/Programme files/Funambol/ sous Windows.

· créer sur le serveur MySQL une base de données nommée funambol et un utilisateur

· lancer le script sql install_funambol-ds-server_schema.sql pour créer les tables du DS server

· Modifier les fichiers <FUNAMBOL_HOME>\tools\tomcat\conf\Catalina\localhost\funambol.xml et <FUNAMBOL_HOME>\tools\tomcat\conf\Catalina\localhost\webdemo.xml :

Spécifier les valeurs correctes pour les attributs de l'élément ressource ; c'est-à-dire : <Resource name="jdbc/fnblds" auth="Container" type="javax.sql.DataSource" username="funambol" password="funambol" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost/funambol" />

· Copier dans le répertoire <FUNAMBOL_HOME>\tools\tomcat\common\lib le MySQL JDBC (c'est-à-dire mysql-connector-java-5.*.*-bin.jar))

Dans ce service, il s'agit de mettre en place un portail web pour la consultation des événements et l'achat d'un ticket, en plus d'un portail d'administration, d'un portail USSD et d'un module de validation.

Lorsque l'utilisateur veut acheter un ticket, il remplit les formulaires adéquats. Parmi ceux-ci, nous avons le formulaire pour le paiement en ligne. Ces informations seront transmises au partenaire de paiement (PayBox) qui entre en contact avec la banque du client et nous renvoie l'autorisation de faire la transaction.

L'achat de ticket à partir des revendeurs nécessite l'apport de l'opérateur. Ce dernier devra ajouter notre service à son serveur d'application USSD. Lors d'un achat, son serveur d'application USSD transmettra à notre serveur MTicket une URL contenant l'ensemble des informations de la transaction.

Le ticket, après avoir été généré en java, sous un format image standard (.jpg), est envoyé au bénéficiaire par l'intermédiaire d'une MMG^25(*) qui permet l'envoi de messages.

A la validation, notre dispositif (Workabout Pro G2) lit le code barres sur le téléphone puis le transmet à notre serveur :

Il s'agira pour nous d'éditer un programme en .NET CF capable d'assurer cette transmission.

Dans le cadre du service de sauvegarde / restauration, nous développons avec l'IDE Netbeans, dans sa version 6.0.1, combiné avec son Mobility pack.

Netbeans est un environnement de développement pour java, placé en open source par Sun sous licence CDDL^26(*). En plus de Java, NetBeans permet également de supporter différents autres langages.

Il comprend toutes les caractéristiques d'un IDE moderne (éditeur en couleur, projets multi-langage, refactoring, éditeur graphique d'interfaces et de pages web).

NetBeans est lui-même développé en Java, ce qui peut le rendre assez lent et gourmand en ressources mémoires.

Mobility pack est le plug-in propre à Netbeans qui permet le développement d'applications J2ME reposant sur MIDP en utilisant un Wireless Toolkit. Il permet surtout l'édition graphique des MIDlets. C'est la raison pour laquelle nous avons préféré NetBeans à Eclipse^27(*) combiné avec son plugin EclipseME.

Le Sun Java Wireless Toolkit (anciennement Wireless Toolkit) ou WTK est l'ensemble des outils proposés par Sun pour développer des applications basées sur une configuration CLDC. Il existe également un Sun Java Toolkit pour CDC.

L'interface graphique est sommaire, il faut un éditeur tiers pour créer le code source, mais toutes les fonctionnalités sont là, c'est pour cela que la plupart des IDE sont des frontends^28(*) pour le WTK.

La version 2.5.2 du toolkit, que nous utilisons d'ailleurs, supporte les API suivantes :

Le diagramme de composants décrit l'organisation du système du point de vue des modules de code (fichier source, exécutable, bibliothèque). Ce diagramme permet de mettre en évidence les dépendances entre les composants (qui utilise quoi ?) et ainsi de mieux organiser les modules.

Un diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de l'infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que leurs relations entre eux. Les éléments utilisés par un diagramme de déploiement sont principalement les noeuds (représentation d'une ressource matérielle), les composants, les associations et les artefacts^31(*). Les caractéristiques des ressources matérielles physiques et des supports de communication peuvent être précisées par stéréotype.

L'utilisation de SyncMl et du serveur Funambol sont un gage de sécurité car ils gèrent de nativement la sécurité des transactions.

Dans la phase d'authentification, le serveur envoie au client un message contenant la balise <Chal> qui représente une demande d'authentification (Challenge en anglais) pour les informations auxquelles le client tente d'accéder. Le client doit alors répondre et donner le login et mot de passe dans une balise <Cred> (Credential en anglais).

SyncML peut utiliser l'accès authentifié par le hachage md5. Le client et le serveur échangent leurs identifiants durant la phase d'authentification, retournant un code d'erreur si le processus s'arrête quelque part. La balise <Cred> est utilisée dans le <SyncHdr> pour fixer le type d'authentification qui sera utilisé dans la phase d'authentification. (Il y a le hachage md5, mais aussi l'encodage base64 et d'autres... Il faut donc que le serveur informe le client du type d'authentification utilisée).

Au niveau du serveur, la résolution des conflits de synchronisation (modification d'une même donnée à la fois sur le client et le serveur) revient à la charge du Sync Engine (moteur de synchronisation) et s'effectue en s'appuyant sur les ancres.

La stratégie de sécurité pour ce service est déployée à plusieurs niveaux :

L'administrateur se connecte au portail grâce à un login et un mot de passe crypté par hachage MD5. Il peut ainsi procéder aux tâches qui lui sont dévolues (gestion des événements, création d'un nouveau compte pour l'organisateur d'un nouvel événement).

L'organisateur d'événement peut aussi se connecter grâce à son login et son mot de passe. Sa vue est cependant restreinte à son cadre d'organisation, c'est-à-dire qu'il ne peut voir et agir que sur son événement.

La sécurité de ce module est totalement assurée par le partenaire de paiement (Paybox). L'ensemble des phases de paiement à réaliser entre l'acheteur et le système est entièrement crypté et protégé. Le protocole utilisé est SSL^32(*) couplé à de la monétique bancaire. Il nous suffit juste de nous mettre en HTTPS^33(*). Dans ce cas, un cadenas fermé apparaît en bas de la fenêtre du logiciel de navigation.

Pour s'assurer que le numéro généré pour ce ticket est unique, nous utilisons la fonction uniqid() de php :

Cette fonction retourne un identifiant préfixé unique, basé sur l'heure courante, en micro-secondes. Le paramètre prefix est optionnel mais peut servir à identifier facilement différents hôtes, si nous générons simultanément des fichiers depuis plusieurs hôtes, à la même micro-seconde. Depuis PHP 4.3.1, prefix peut prendre jusqu'à 114 caractères.

Si le paramètre optionnel more_entropy est TRUE , uniqid() ajoutera une entropie "combined LCG" à la fin de la valeur retournée, ce qui renforcera encore l'unicité de l'identifiant.

Sans prefix (préfixe vide), la chaîne retournée fera 13 caractères. Si more_entropy est à TRUE , elle fera 23 caractères. En combinant cette méthode au hachage md5, nous obtenons un code de 32 caractères :

Le code généré, ainsi que les autres références du ticket, sont stockés au niveau de la base de données. Un process java plus sécurisé se chargera de parcourir la base et générer les tickets en instance. Une génération avec un script php rendrait l'opération visible au niveau de la page web.

Le MMS transmis à un bénéficiaire, après une transaction, ne peut plus être utilisé par un autre appareil mobile, en d'autres termes ce MMS ne peut plus être transféré. Pour cela, l'Open Mobile Alliance (OMA) a spécifié un modèle de gestion des droits [OMADRM^34(*)], dont la version 1 actuelle prévoit trois niveaux de protection :

- l'usage du contenu téléchargé est illimité (ex : autant d'écoutes que l'on veut)

- l'usage du contenu téléchargé est régi par des droits (ex : 3 écoutes maximum).

- le contenu peut être transmis (sans les droits), possibilité de marketing viral.

On doit néanmoins mettre l'accent sur le fait que tous les terminaux n'ont pas encore intégré de mécanisme de protection des droits. En outre, malgré la normalisation par l'OMA, il existe encore un certain nombre de modèles ayant une implémentation propriétaire des DRM. Cependant, un contenu protégé par un DRM, mais envoyé sur un mobile ne supportant pas ce DRM, est rejeté.

Une seconde version de DRM est prévue par l'OMA, utilisant un cryptage des droits d'accès par une clé publique (PKI).

Pour protéger un fichier par Combined Delivery (pour rendre le message, entre autres, non transférable) celui-ci doit être encapsulé dans une enveloppe de type : application/ vnd.oma.drm.rights+xml

C'est à partir de cette interface que l'abonné choisit de sauvegarder ou restaurer ses données, ou bien de paramétrer ce service. Il peut choisir une de ces options en utilisant les touches haut et bas de son téléphone. Pour valider un choix, il peut appuyer sur le bouton situé en haut à droite (option " lancer "). Pour sortir de cet écran, il suffit d'utiliser l'option "sortir".

Cet écran est le front-office de MTicket permettant à un internaute d'acheter un ticket pour un des événements représentés par une image cliquable.

Cet écran du backoffice de MTicket permet d'avoir une vue sur les événements présentés au niveau du front.

2SI compte, à travers cette plateforme, poser les jalons de nouveaux types de SVA.

Il s'agissait, d'une part, d'assurer la pérennité des données stockées dans le téléphone mobile. Ceci a été réalisé, en partie, dans le service SOS PIN avec la sauvegarde des contacts. En perspective, il peut être extensible à une sauvegarde de tous les types de données du mobile en manipulant le système de gestion des fichiers du terminal grâce aux packages adéquats proposés par J2ME.

D'autre part, la plateforme propose de dématérialiser les tickets permettant d'accéder à des services, en particulier des évènements. L'acquisition d'un ticket virtuel est possible désormais à partir du portail web. Il reste cependant la contribution de l'opérateur pour implanter ce service au niveau de son serveur d'application pour le rendre utilisable à partir du réseau de recharge de crédit. L'achat d'un ticket en mode WAP ou par serveur vocal est aussi prévu pour multiplier les modes d'accès au service MTicket.

L'utilisation des codes-barres ouvre, quant à elle, l'ère de la portabilité d'un certain type d'information : ici il s'agissait d'un numéro de ticket. L'intégration des codes barres 2D pourrait largement augmenter ce volume : une chaine d'informations complète sur un objet précis.

La réalisation de cette plateforme, ainsi articulée autour des services pour téléphones mobiles nous a permis d'explorer ce vaste domaine en approfondissant notre connaissance en réseaux pour mobiles, en synchronisation de données et en programmation java pour l'embarqué, trois concepts fondamentaux dans l'informatique d'aujourd'hui.

Bibliographie

Wébographie

API : Ensemble de fonctions courantes de bas niveau permettant de programmer des applications de haut niveau.

Back-office : partie d'un portail web ou d'un système informatique qui permet à d'administrer et de gérer ce dernier.

Conteneur : Désigne une classe de fichiers qui renferme des informations codées de façon variable.

Emulateur : Classe de logiciel permettant de faire fonctionner un système comme un autre.

Embarqué : se dit d'un système informatique destiné à fonctionner dans un véhicule ou un appareil portable comme un avion ou un PDA.

Front-office : désigne la partie qui prend en charge l'interface d'une application. Dans les sites web commerciaux il permet de commander en ligne

Hachage: méthode permettant de diviser une liste de données en listes plus petites contenant les éléments de la première qui ont des points en commun.

IDE : environnement de développement intégré réunissant tous les outils nécessaires à la création d'application, aussi complexe qu'elles soient.

Machine virtuelle : machine abstraite simulée au sein d'une autre machine bien réelle celle-là, et utilisée comme environnement d'exécution d'un langage portable de haut niveau.

Monétique : ensemble des traitements électroniques, informatiques et télématiques nécessaires à la gestion de cartes bancaires ainsi que des transactions associées.

Open Source : Licence de logiciel qui autorise la modification et la redistribution gratuite.

Plateforme : Ensemble de logiciels facilitant le développement ou l'exploitation de programmes

PIM : type d'application qui fonctionne comme un organiseur de données personnelles, par extension, signifie ces données.

Session : Désigne la durée écoulée entre la mise en route d'un processus et son arrêt.

Transaction: ensemble d'opérations modifiant des données, devant être effectuées toutes en même temps ou une par une.

WAP : Protocole d'application sans fil qui permet de se connecter à Internet grâce à un téléphone mobile.

Décision fixant la liste des valeurs ajoutées au Sénégal

Vu la loi n° 2001-15 du 27 décembre 2001 portant code des télécommunications ;

Vu la loi n°2002-23 du 4 septembre 2002 portant cadre de régulation des entreprises concessionnaires de services publics ;

Vu le décret n° 2003-63 du 17 février 2003 fixant les règles d'organisation et de fonctionnement de l'Agence de Régulation des Télécommunications ;

Vu le décret n° 2003-64 du 17 février 2003 relatif aux fréquences et bandes de fréquences radioélectriques, aux appareils radioélectriques et aux opérateurs de ces équipements ;

Vu le décret n°2003-215 du 17 avril 2003 nommant les membres du Conseil de Régulation de l'Agence de Régulation des Télécommunications ;

Vu le décret n°2003-361 du 28 mai 2003 portant nomination du Directeur Général de l'Agence de Régulation des Télécommunications ;

Article premier : La liste des services à valeur ajoutée visés à l'article 19 du code des télécommunications est fixée comme suit :

L'échange, la lecture et le stockage d'informations, sous forme de messages de données, entre des machines se trouvant dans des sites distants. Le destinataire du message n'est pas nécessairement présent au moment de l'envoi du message.

Elle est régie par les recommandations de l'Union Internationale des Télécommunications X-400 et X- 500 de l'UIT-T.

L'échange (la réception et/ou l'envoi) et l'enregistrement de messages vocaux dans des serveurs vocaux, accessibles à partir d'équipements terminaux appropriés.

Elle est régie par la recommandation de l'Union Internationale des Télécommunications X-485 de l'UIT-T.

La mise à la disposition des usagers d'accès à des serveurs, interactifs ou non, pour enregistrer, lire ou écouter des messages à partir d'équipements terminaux appropriés.

L'échange de données formatées de manière standard entre les différentes applications tournant sur les ordinateurs de partenaires commerciaux avec un minimum d'interventions manuelles.

La mise en place de serveurs permettant de transmettre et de reproduire à distance divers documents (lettres, photos et dessins) avec la possibilité d'archivage et d'accès à ces documents.

L'accès à des informations en ligne, en temps réel et sans intervalles d'attente.

7/ Services d'accès aux données, y compris la recherche et le traitement des données :

L'accès à des informations stockées dans des serveurs et/ou des bases de données en utilisant notamment l'infrastructure du réseau téléphonique public ou des réseaux de transmission de données et des interfaces d'adaptation.

Le transport et l'échange de fichiers et de données informatiques, constitués de textes et d'images, éventuellement animées, entre des machines hétérogènes se situant sur des sites distants. Il permet également le téléchargement de fichiers et de données à partir de machines distantes.

L'adaptation des protocoles utilisés par des machines différentes, dont la représentation interne des données est différente, afin de permettre la communication entre ces machines.

La messagerie électronique, le transfert de fichiers, la connexion à une machine distante, le dialogue sous forme de messages écrits sur des sujets variés entre des groupes d'utilisateurs en temps réel et la recherche d'informations dans des serveurs.

- le SMS : message texte envoyé vers un téléphone mobile depuis un autre téléphone mobile ou depuis un ordinateur ;

- le WAP (Wireless Application Protocol) : Protocole d'application sans fil qui permet de se connecter à Internet grâce à un téléphone mobile ;

- l'I-Mode : permet à ses utilisateurs un accès Data à des services au travers d'Internet. service destiné à l'univers des télécoms, il peut être également déployé sur des terminaux aussi divers que les consoles de jeux, les télévisions, etc. ;

- Le MMS (Multimedia Messaging Service) : service de messagerie pour les appareils mobiles qui s'apparente au SMS. Le MMS permet l'envoi automatique et immédiat de messages multimédias personnalisés de téléphone à téléphone ou d'un téléphone à un compte e-mail. Outre les contenus textuels habituels des messages courts, les messages multimédias peuvent aussi contenir des photos, des graphiques, des clips audio et vocaux.

Article 3 - Les prestataires des services à valeur ajoutée peuvent demander à tout moment au Directeur général de l'ART, la reconnaissance d'un nouveau service de télécommunications comme service à valeur ajoutée. En cas d'accord, le nouveau service pourra immédiatement faire l'objet d'une offre au public et sera intégré dans la liste des services à valeur ajoutée à la prochaine révision.

Article 4 - La présente décision entre en vigueur à la date de sa signature et sera publiée et communiquée partout où besoin sera.

* ¹ Joint Requiement Planning : Technique d'aide à l'expression des besoins par les utilisateurs

* ² Joint Application Development : Cette technique organise le processus de conception de façon à y faire participer les utilisateurs

* ³ Time-box : cette technique limite la durée de la réalisation à une enveloppe-temps maximale

* ⁶ Uu : interface radio entre l'UTRAN (UMTS Terrestrial Radio Access Network) et l'UE (User Equipement - Equipement de l'utilisateur)

* ⁸ Streaming : envoi de flux continu d'informations qui seront traitées instantanément avec la possibilité d'afficher les données avant que l'intégralité du fichier ne soit téléchargée, l'objectif étant de gagner en rapidité

* ¹¹ Ensemble des mécanismes permettant à une entreprise de créer de la valeur à travers la proposition de valeur faite à ses clients

* ¹⁸ IVR : interactive voice request - système de réponse automatique personnalisable proposant à l'appelant une liste de services

* ¹⁹source O₂Sicap USSD gateway : www.sicap.com/store/attachments/00038.pdf

* ²⁰ Compilation à la volée : technique visant à améliorer la performance de systèmes bytecode compilés par la traduction du bytecode en code machine natif au moment de l'exécution

* ²¹ OBject EXchange est un protocole de l'IrDA (Infrared Data Association) proche d'une version binaire de HTTP. Initialement créé par l'IrDA pour les transports sur faisceaux infrarouges, il a été par la suite adapté à d'autres canaux à bande passante réduite, notamment Bluetooth.

* ²³ Les entreprises qualifiées de pure players sont des entreprises exerçant uniquement leurs activités sur internet : elles ne possèdent pas de réseau de distribution physique.

* ²⁵Multimedia Mobile Gateway: plate-forme de messagerie de bout en bout pour les échanges de données mobiles sur plusieurs supports. Elle permet de connecter des réseaux de télécommunication ayant des architectures, des protocoles ou des services différents.

* ²⁷ Un autre IDE open source, extensible, universel et polyvalent, permettant potentiellement de créer des projets mettant en oeuvre n'importe quel langage de programmation.

* ²⁹ Over The Air Programming (OTA) est une méthode de distribution de logiciels et de mises à jour destinée aux appareils mobiles (téléphone portable, smartphone...). L'avantage d'une installation via OTA est que l'acquisition du programme se fait depuis le réseau sans-fil de l'appareil (WAP, MMS...).

* ³⁰ Java Specification Requests émises par le Java Community Process, qui décrivent les spécifications et technologies proposées pour un ajout à la plateforme Java

* ³¹ composant consommé ou créé durant l'une des étapes du processus de déploiement.

* ³² Secure Sockets Layers -couche de sockets sécurisée- est un procédé de sécurisation des transactions effectuées via Internet