Service de covoiturage nouvelle-g´en´eration
G. B´edard Sic´e, E. Cantin, F. Courville, J.-M. Gingras, O. Lamarche, F. N´eron et T. Tran
Universit´e de Sherbrooke Facult´e de g´enie
D´epartement de g´enie informatique et g´enie ´electrique info@lzgo.com
R´esum´e—Cet article pr´esente le projet LzGo, une plateforme de covoiturage nouvelle-g´en´eration. Cette plateforme permet de faciliter l’organisation du covoi- turage interurbain entre des conducteurs et des passa- gers. La solution d´evelopp´ee favorise le covoiturage en
´
etant plus accessible par ses faibles coˆuts d’utilisation, plus simple en mettant `a profit les nouvelles techno- logies et plus social en interagissant avec les m´edias sociaux. Tout d’abord, une d´efinition plus d´etaill´ee du syst`eme sera pr´esent´ee. Puis, les choix technologiques seront abord´es, tels que l’architecture du syst`eme et les choix technologiques effectu´es. Finalement, il sera question des m´ethodes de validation et de tests utilis´ees au cours du d´eveloppement du projet.
Mots-cl´es—Service de covoiturage, Ruby on Rails, iOS, Android, SaaS, Application web
I. Mise en contexte A. Introduction et motivation
L’utilisation du covoiturage est en pleine croissance au Qu´ebec. En effet, cette alternative `a l’utilisation de la voiture personnelle est une option de plus en plus choisie car elle est plus ´ecologique et ´economique.
Le projet LzGo est con¸cu pour devenir un joueur majeur dans cet ´ecosyst`eme. Pour se d´emarquer des services exis- tants, LzGo suit la vague du Web 2.0 ax´ee sur la simplicit´e et l’interactivit´e. L’int´egration des m´edias sociaux avec une interface simple et intuitive rend l’exp´erience de l’uti- lisateur plus sociale et durable. Par exemple, la recherche de d´epart mets l’emphase sur l’interaction avec son r´eseau social personnel tels que ses amis Facebook.
Ensuite, le service sera offert ´egalement en version mo- bile pour t´el´ephones intelligents, dont l’utilisation est en croissance fulgurante. Les utilisateurs pourront ainsi par- courir les offres, acc´eder `a l’information sur leurs d´eparts et recevoir des notifications directement sur leur t´el´ephone, facilitant la dynamique passager-conducteur.
Le service sera offert sous forme de forfaits mensuels et sans frais d’utilisation suppl´ementaires. Avec le mod`ele utilis´e, les utilisateurs conducteurs et passagers effectue- ront des ´economies par rapport aux coˆuts demand´es par les comp´etiteurs actuels. Le covoiturage ´etant alors non seulement ´ecologique mais ´egalement plus ´economique, il sera donc plus accessible `a tous.
Ainsi, la mission du projet est d’amener une alternative aux covoitureurs qui soit plus simple, plus sociale et plus
accessible.
B. ´Etat de l’art
Etant donn´´ e le mod`ele d’affaires du projet LzGo, le domaine qui lui rapproche le plus est celui du logiciel en tant que service (de l’anglais software as a service ou SaaS).
Les technologies utilis´ees par les entreprises faisant af- faire dans cet industrie ont longtemps tourn´e autour de la pile LAMP et ses variantes. En effet, la combinaison de Linux, Apache, MySQL et PHP a d´ej`a fait ses preuves et est devenue le standard du domaine.
Les logiciels offerts en tant que service sont en g´en´eral tr`es flexibles face `a la demande. Leur architecture permet une ´evolutivit´e horizontale, assurant un niveau de service minimum relev´e. Lorsque la charge d’utilisation est trop grande, il est possible de dynamiquement d´eployer un nouveau serveur pour combler cette demande.
De plus, le d´eveloppement et d´eploiement de nouvelles fonctionnalit´es se fait plus rapidement que dans un mod`ele traditionnel de par le fait que l’application est servie depuis un point central. L’utilisateur n’a donc plus besoin de faire de mises `a jour pour profiter des plus r´ecentes fonctionnalit´es.
Ensuite, l’utilisation d’analytiques permettent aux d´e- veloppeurs de facilement cibler leurs changements pour s’assurer de mieux satisfaire la demande de leurs clients.
Les applications de type Saas, quoique souvent tr`es diff´erents les uns des autres, sont souvent bˆatis sur les mˆemes pilliers. Par exemple, on retrouve souvent un ni- veau d’interface de programmation (API ou application programming interface en anglais) permettant `a des tierces parties d’avoir acc`es `a certaines fonctionnalit´es sans uti- liser l’interface utilisateur. Ces interfaces offrent toutes sortes d’avantages, comme le d´eveloppement d’applica- tions mobiles ou mˆeme l’automatisation de tˆaches via des scripts. Aussi, ´etant donn´e la pr´esence en ligne de l’application, on retrouve souvent une emphase sur la collaboration entre les utilisateurs.
Servir une application en ligne offre de nombreux avan- tages aux utilisateurs aussi. Entre autres, le fait de ne rien avoir `a d´eployer peut engendrer des ´economies de temps si- gnificatives. De plus, ces services sont g´en´eralement offerts
`
a un prix moins cher que la comp´etition en application
de bureau. Finalement, ´etant donn´e que ces applications sont h´eberg´es en ligne, le client n’a pas `a se soucier des investissements de mat´eriel informatique.
Ceci ´etant dit, les entreprises offrant des logiciels en tant que service ont aussi plusieurs d´efis `a relever, notamment en terme de s´ecurit´e des donn´ees. L’ann´ee 2011 a ´et´e particuli`erement difficile pour la s´ecurit´e des donn´ees.
Plusieurs grands sites, tel que Sony Playstation Network, on vu leurs failles de s´ecurit´e se faire exploiter, mettant en danger les donn´ees de plusieurs millions d’utilisateurs.
C. D´efi technique
Tout d’abord, le syst`eme doit offrir les fonctionnalit´es primaires d’un service de covoiturage, comme annoncer un d´epart en tant que conducteur et s’inscrire `a un d´epart en tant que passager. Ces op´erations de base doivent au minimum ˆetre tout aussi faciles et agr´eables `a utiliser que sur les services existants, sans quoi l’utilisateur n’aura pas int´erˆet `a effectuer une migration vers LzGo.
D’autre part, les fonctionnalit´es qui permettront LzGo
`
a se d´emarquer de la comp´etition devront ˆetre bien int´e- gr´ees `a l’ensemble du syst`eme en place. Une des grandes nouveaut´es amen´ee est l’interaction du syst`eme avec les m´edias sociaux. Cela permettra d’´etendre la visibilit´e du covoiturage non seulement `a l’int´erieur du service lui- mˆeme, mais ´egalement jusque dans le r´eseau social des utilisateurs. Par exemple, un conducteur pourra cr´eer un d´epart sur LzGo et ensuite le partager `a tous ses amis Facebook ou encore `a sesfollowers Twitter. Ils pourront alors s’inscrire facilement au mˆeme d´epart. Une autre fonctionnalit´e int´eressante avec l’interaction des m´edias sociaux est que le syst`eme mettra en ´evidence les d´eparts effectu´es par son r´eseau social existant, encourageant donc les gens `a voyager avec des connaissances et ainsi am´e- liorer leur exp´erience de covoiturage. Ces fonctionnalit´es am`enent de nouvelles op´erations possibles `a l’utilisateur et il faudra s’assurer qu’elles soient faciles `a effectuer et qu’elles ne nuiront pas `a l’ergonomie de l’interface.
Aussi, le d´eveloppement d’applications mobiles repr´e- sente ´egalement un d´efi `a plusieurs niveaux. Tout d’abord, il faut que le serveur d’application puisse communiquer au- tant avec l’application Web qu’avec les diff´erents appareils mobiles. Ceci engendre un d´efi au niveau de l’architecture de l’application ainsi qu’au niveau de l’infrastructure de d´eploiement.
De plus, il est important de consid´erer que contraire- ment `a l’application Web, nous ne pouvons pas garantir que les utilisateurs des plateformes mobiles mettront `a jour leurs applications. Il est donc important de pouvoir faire
´
evoluer l’application Web sans briser le fonctionnement des application mobiles ant´erieurs. Pour ce faire, il faut ´etablir, d`es le d´epart, une strat´egie de versionnement sur laquelle nous pourrons nous fier.
Egalement, la conception des interfaces mobiles exigera´ un tout autre mode de pens´ee qu’avec celles du Web.
Les lignes directrices `a suivre quant `a l’ergonomie des
interfaces mobiles d´efinies par Apple [1] devront ˆetre suivies. De plus, il y a des d´elais avant la mise en ligne d’une application sur le magasiniTunes. Il faut donc tenir compte de ces normes lors du d´eveloppement sur cette plateforme.
Finalement, l’important sera de s’assurer que l’int´egra- tion de toutes ces fonctionnalit´es rendent l’exp´erience de covoiturage plus facile et agr´eable que chez les comp´eti- teurs. Dans ce mˆeme ordre d’id´ees, il faudra limiter le nombre de bogues au minimum. Pour ce faire, une stra- t´egie rigoureuse des principes dutest-driven development sera privil´egi´ee.
II. Description du syst`eme A. Architecture globale
1) Vue d’ensemble: L’architecture globale du syst`eme se compose de trois principaux sous-syst`emes : l’application Web, l’application pouriOS et l’application pourAndroid.
Cette organisation est pr´esent´ee `a la figure 1.
2) Application Web: L’application Web est une applica- tionRuby on Rails [2], architectur´ee selon le patron MVC (Model View Controller). Le patron MVC est fortement encourag´e parRails, pour ne pas dire impossible `a ´eviter.
Cela dit, ce patron est une meilleure pratique du Web, car il permet de s´eparer la logique d’affaires de la repr´esenta- tion visuelle des donn´ees.
3) Applications mobiles: Les applications mobiles com- muniquent avec le syst`eme `a travers l’application Web.
Cependant, plutˆot que d’utiliser des vues graphiques, elles utilisent des vues de structures de donn´ees selon le format JSON et organis´ees selon la structure REST (REpresen- tational State Transfer). Cette structure permet d’utiliser des librairies tierces pour acc´eder et recr´eer les donn´ees de l’API plutˆot que d’avoir `a reconcevoir ce syst`eme.
4) Infrastructure de d´eploiement: Du fait de son orga- nisation, l’application Web est centrale `a tout le syst`eme.
L’infrastructure sur laquelle elle fonctionnera doit donc ˆ
etre capable de r´epondre ad´equatement `a la demande.
L’architecture envisag´ee est donc une architecture distri- bu´ee, dont les secteurs les plus sollicit´es pourront se mettre
`
a l’´echelle rapidement et facilement. Sur le sch´ema pr´esent´e
`
a la figure 2, on peut apercevoir cinq machines diff´erentes, mais ce nombre est sujet `a de grandes variations. Les serveurs Web seront pla¸c´es derri`ere un load balancer, qui leur distribuera les requˆetes entrantes afin de r´epartir la charge entre eux.
La trajectoire que prendra la requˆete d’un client `a travers l’infrastructure est la suivante :
– Passer dans la couche de r´epartition de charge (load balancing en anglais) pour ˆetre assign´ee `a un serveur Web
– Si c’est une requˆete pour un objet statique, tel une image ou un fichier JavaScript, le serveur Web re- tourne l’objet demand´e. Sinon, il envoie la requˆete au serveur d’application.
Application Web (Ruby on Rails)
Application iOS Application Android Navigateur
Figure1. Architecture des diff´erentes applications
– Le serveur d’application traite la requˆete et fait pos- siblement des requˆetes sur la base de donn´ees.
– Si la requˆete g´en`ere des notifications, celles-ci sont envoy´ees au serveur de notifications, qui les renverra aux utilisateurs concern´es selon leurs pr´ef´erences.
Chacun des serveurs Web comportera les logiciels sui- vants :
– Un serveur Web (nginx)
– Un serveur d’application Ruby (thin)
– Un serveur de base de donn´ees esclave (MySQL) Ceux-ci, dont le sch´ema est pr´esent´e `a la figure 3, seront pr´esents en nombre variable et lanc´es dynamiquement afin de satisfaire `a la demande.
Esclave (MySQL)
Serveur d'application
(thin)
Serveur Web (nginx)
Serveur Web
Figure3. Sch´ema d’un serveur Web dans l’infrastructure envisag´ee
En ce qui concerne le serveur de notifications, il enverra
les notifications au navigateur Web via des WebSockets.
Il s’occupera aussi des notificationsiOS,Android, SMS et courriel. Ce sont sp´ecialement ces derni`eres qui n´ecessitent un serveur `a part. Par exemple, dans le cas des notifica- tionsiOS qui sont envoy´ees `a travers les serveurs d’Apple, Apple demande qu’une seule connexion TCP soit ´etablie, et que tous les envois y passent. Les notifications Android et SMS ont le mˆeme genre de limitation. De plus, il semble logique de regrouper au mˆeme endroit toutes les mani`eres de rejoindre un usager.
B. Choix technologiques
1) Choix logiciels: Le premier choix crucial `a prendre
´
etait celui concernant la plateforme de d´eveloppement web. Les capacit´es d’extensions et la communaut´e ex- trˆemement pr´esente autour de la technologie open-source Ruby on Rails a motiv´e l’´equipe `a se diriger vers cette plateforme. La plateforme a d´efinitivement fait ses preuves sur le Web avec les sites commeTwitter,Github etGrou- pon. Le manque d’organisation du langage PHP et la difficult´e d’int´egration du langage Java a conduit l’´equipe
`
a s’´eloigner de ces deux choix.
Une couche API de type REST retournant des r´eponses sous le format Javascript Object Notation (JSON) est utilis´e pour communiquer entre les application mobiles et l’application Ruby on Rails. Cette couche, bˆatit avec le module Grape [3], est mont´ee en tant que intergiciel (middleware en anglais). C’est ce module qui s’occupe, entre autre, du versionnement et de l’internationalisation de l’API. C’est aussi cette couche qui sert d’interm´ediaire entre les applications mobiles et la base de donn´ees.
Les applications mobiles ne se connectent donc jamais aux contrˆoleurs dans l’application Web, ni `a la base de donn´ees. Cela simplifie l’architecture, ´eliminant une cer- taine complexit´e des applications mobiles et la gestion des
Esclave
Serveur d'application
Serveur Web Serveur Web 1
Load balancer Maître Serveur de base de données
Serveur de répartition
Serveur de notifications (Web) Traitement des notifications
(iOS, Android, SMS, email)
Serveur de notifications
Navigateur Application iOS Application
Android
Serveur push d'Apple Serveur push Android Service d'envoi de SMS
Mailer
Esclave
Serveur d'application
Serveur Web Serveur Web n
Figure2. Sch´ema de l’infrastructure envisag´ee
connexions `a la base de donn´ees.
Le type de base de donn´ees utilis´e par l’´equipe est MySQL[4]. L’exp´erience des membres avec ce type de base de donn´ees et la bonne compatibilit´e avec la plateforme Ruby on Rails ont rendu le choix facile.
Les plateformes mobiles offraient aussi un choix consi- d´erable : l’utilisation d’un environnement de d´eveloppe- ment multi-plateforme (iOS, Android) ou l’utilisation des librairies natives des plateformes respectives. L’´equipe a pench´e sur ce dernier, permettant un d´eveloppement plus sp´ecifique et mieux int´egr´e `a la plateforme vis´ee.
Pour le syst`eme de contrˆole de version, l’ensemble des membres s’est dirig´e versgit [5]. En fait, ce syst`eme facilite
´
enorm´ement le d´eveloppement de fonctionnalit´es en paral- l`ele. Une ´etude approfondie des diff´erentes possibilit´es ont
motiv´e cette d´ecision.
2) Choix mat´eriels: Le d´eveloppement mobile se fait sur deux types de plateformes diff´erentes. La premi`ere est la plateforme iOS, qui englobe la lign´ee de produits iPhone et iPod Touch. Elle repr´esente la plus grande part de march´e des t´el´ephones intelligents et il s’agit donc d’un incontournable. Le d´eveloppement en tant que tel s’effectue sur les mod`eles iPhone 3GS, 4S et 5.
La deuxi`eme plateforme est Android, qui est en constante expansion en terme de part de march´e dans les derni`eres ann´ees. Le d´eveloppement se fait sur des unit´es d’anciennes g´en´erations (Google Nexus One, LG Optimus One), permettant donc de mettre une emphase particuli`ere sur la performance de l’application.
Figure4. Flux de travail du d´eveloppeur
III. R´esultats, validation et test A. M´ethodes de validation
La validation et les tests sont une ´etape essentielle dans le d´eveloppement informatique. L’´equipe a ´etudi´e la situation et en est venu `a une entente sur les diff´erents principes de fonctionnement du flux de travail, pr´esent´e `a la figure 4. Les points suivants ont ´et´e retenus :
– Utilisation du syst`eme de d´epˆot de code sourcegit – D´eveloppement des fonctionnalit´es sur diff´erentes
branches
– Automatisation de la compilation et des tests des applications
– Couverture de code par les tests (>80%)
– Publication de la derni`ere version de la branche prin- cipale
Lorsqu’un d´eveloppeur travaille sur une nouvelle fonc- tionnalit´e, il se doit d’inclure les tests unitaires, fonction- nels et d’int´egration qui concernent cette fonctionnalit´e.
Il doit aussi s’assurer qu’aucun autre test soit bris´e avant d’int´egrer sa fonctionnalit´e dans la branche principale. Si les tests ne passent pas, l’´equipe est avertie par courriel.
Ce courriel contient toutes les informations n´ecessaires `a la correction du ou des tests fautifs.
L’automatisation de la v´erification des tests et de la compilation de l’application est faite avec Jenkins. Lors- qu’un changement est pouss´e sur la branche principale du serveur, il compile l’application et v´erifie si les tests ex´ecutent tous avec succ`es. Cet outil permet facilement de d´etecter un dysfonctionnement de l’application et de le r´egler rapidement. Les personnes concern´ees peuvent corriger ce probl`eme et s’assurer de la bonne sant´e de LzGo sur l’application Jenkins du serveur de l’´equipe.
La derni`ere version de la branche principale est publi´ee sur un sous-domaine du site Web. `A l’aide de l’authenti- fiant LDAP, l’´equipe peut permettre un acc`es restreint `a l’application. Cela permet `a l’´equipe de tester l’application dans un environnement d’utilisation r´eel et d’avoir la derni`ere version de l’application sur la branche principale
`
a port´ee de la main.
Pour valider ses interfaces graphiques, l’´equipe compte utiliser l’aide de diff´erents outils statistiques analytiques.
Avec celles-ci, l’´equipe peut prendre compte des diff´erentes
actions de l’utilisateur et ainsi ajuster son interface. Ces outils sont notamment fournis par Google et permettent d’augmenter consid´erablement la qualit´e de l’application si les statistiques sont bien analys´ees.
L’application passera un stadealpha etbeta. La version alpha sera ferm´ee et sera r´eserv´ee aux amis et `a la famille de l’´equipe (Friends & Family) de fa¸con `a obtenir de la r´etroaction `a travers un contact direct avec les usagers.
La phasebeta sera aussi ferm´ee, mais `a base d’invitations.
L’´equipe pourra alors publier des codes d’invitation qui permettront l’acc`es `a l’application web. Les usagers pour- ront envoyer leurs probl`emes/commentaires `a travers un formulaire simple qui sera transmis `a l’´equipe.
B. R´esultats des tests
La couverture du code est un indicateur relativement fiable de la qualit´e et de la quantit´e des tests. L’´equipe peut alors s’assurer que le fonctionnement des tests ´equivaut au fonctionnement g´en´eral des diff´erents modules. L’ap- plication Web contient actuellement 842 lignes de code effectives (lignes contenant au moins une instruction), dont 743 sont couvertes par les tests, pour un pourcentage de couverture de 88,42%.
IV. Conclusions et travail futur
A. Conclusions
Le covoiturage qu´eb´ecois et nord-am´ericain sont des domaines qui d´emontrent encore beaucoup de potentiel.
Comme l’a faitAmigo Express il y a 6 ans, le projet LzGo cherche `a exploiter les lacunes des solutions pr´esentement offertes.
L’application Web, bˆatit sur Ruby on Rails, offrira bien sˆur les fonctionalit´es de base des syst`emes de covoiturage : annoncer des d´epart et s’incrire sur un d´epart. Cependant, LzGo en fera bien plus aussi : la plateforme misera sur les applications mobiles et une int´egration significative avec les m´edias sociaux pour assurer une exp´erience plus simple, plus sociale et plus accessible aux utilisateurs.
Voil`a donc pourquoi tous les volets de la solution sont importants : chaque module compl`ete le casse-tˆete pour cr´eer une plateforme coh´erente.
Etant donn´´ e l’importance de l’exp´erience utilisateur, certains choix technologiques ont ´et´e d´ecid´es en cons´e- quence. Les application mobiles, par exemple, sont d´e- velopp´ees dans leurs environnements natifs plutˆot que d’utiliser un framework `a multiples d´eploiements. Aussi, une infrastructure qui favorise la redondance sera de mise pour assurer un service de qualit´e, mˆeme lors des p´eriodes charg´ees.
La strat´egie de test donne la possiblit´e de d´evelopper en int´egration continue. Les tests unitaires, fonctionnels et d’int´egration permettent de voir les r´egressions et de les corriger avant qu’ils affectent le d´eveloppement des autres.
B. Le¸cons apprises
Le projet LzGo offre un apprentissage constant `a tous les membres de l’´equipe. Que ce soit du point de vue technique ou du point de vue de gestion de projet, les le¸cons apprises sont nombreuses. En voici quelques-unes.
– Il est important d’avoir l’avis de tous les membres lors dessprints planning. Ceci assure des sprints plus r´ealisables.
– Il faut absolument prioriser les fonctionalit´es du ba- cklog au d´epart et ne pas avoir peur d’en couper.
– Malgr´e avoir planifi´e du temps pour le ramp up de l’´equipe, le fardeau de travailler dans un nouveau langage est tout de mˆeme consid´erable.
– Mettre l’emphase sur l’exp´erience utilisateur force `a faire des choix technologiques qui sont parfois coˆu- teuses en terme d’heures de travail.
C. D´eveloppements futurs
Plusieurs avenues s’ouvrent `a la plateforme LzGo pour assurer la bonne continuit´e de la solution.
Premi`erement, un travail de r´eusinage sera n´ecessaire dans tous les modules afin d’assurer une meilleure lon- g´evit´ee au projet. ´Etant donn´e que le projet sera actif
`
a long terme, il est essentiel d’assurer que celui-ci soit maintenable et extensible.
Deuxi`emement, l’´equipe devra se pencher sur le d´evelop- pement de l’applicationAndroid. Il faudra r´epliquer toutes les fonctionalit´es offertes sur la plateforme iOS tout en assurant la meilleure exp´erience utilisateur possible.
Troisi`emement, plusieurs id´ees ont ´et´e lanc´e pour des nouvelles fonctionnalit´es. Quoiqu’il reste toujours des ana- lyses `a effectuer, il est tout `a fait possible d’´etendre la solution courante pour mieux accomoder autres sc´enarios de covoiturage.
Finalement, une pouss´ee constante en r´eglage de bogues sera n´ecessaire avant et apr`es le lancement afin de s’assu- rer, encore une fois, de la meilleure exp´erience utilisateur possible.
Quoi qu’il en soit, il est certain que le futur du projet sera une combinaison de ces lignes directrices.
Acknowledgment
L’´equipe LzGo aimerait remercier l’´equipe professorale de S7 de l’Universit´e de Sherbrooke, ainsi que le D´e- partement de G´enie ´Electrique et Informatique pour leur soutien tout au long du d´eveloppement de LzGo.
R´ef´erences
[1] Apple. (2012) Human interface guidelines.
[Online]. Available : https ://develo-
per.apple.com/library/ios/documentation/userexperience/
conceptual/mobilehig/Introduction/Introduction.html
[2] 37Signals. (2012) Ruby on rails homepage. [Online]. Available : http ://rubyonrails.org
[3] J. Cheung and M. Bleigh. (2010) Grape|rest-like api microfra- mework. [Online]. Available : http ://intridea.github.com/grape/
[4] (2012) Mysql : : The world’s most popular open source database.
[Online]. Available : https ://www.mysql.com/
[5] (2012) Git. [Online]. Available : http ://git-scm.com/
