IUP GMI Master 1ere année Projet Wikiroute Etudiants : Mustapha FODIL Valentin FAÏSSE Tuteurs : Corinne FREDOUILLE, Frédéric DUVERT 09
I. Récapitulatif S1... 3 II. Fonctionnalités à réaliser... 3 III. Fonctionnalités réalisées... 5 1. Utilisateurs... 5 2. Wiks... 5 3. Itinéraires... 6 4. Généralités... 6 IV. Organisation... 7 1. Trac... 7 2. Subversion... 7 3. Netbeans & Eclipse... 7 4. FireBug... 7 5. FirePHP... 8 6. Planification... 8 V. Conception... 10 1. Zend Framework... 10 2. Arborescence... 10 3. Interface utilisateur... 11 4. Technologies... 11 VI. Tests... 12 VII. Mise en pratique... 13 1. Quoi tester?... 13 2. Comment tester?... 13 1. PHP_CodeSniffer :... 13 2. PHP_SecAudit :... 14 3. PHP_Depend :... 14 4. PHPUnit... 15 3. Bonus :... 18 VIII. Ouvertures... 19 1. Alternative A... 19 2. Alternative B... 19 IX. Conclusion... 19 2
I. Récapitulatif S1 Dans le cadre du master 1 er année, nous avons choisi de nous lancer dans la réalisation du projet wikiroute. Globalement, le projet consiste en la création d un site internet où les différents visiteurs peuvent s inscrire et partager leurs connaissances de la géographie (création d itinéraire) et des bonnes adresses (création de wiks) où l on peut bénéficier d avantages quelconques. II. Fonctionnalités à réaliser Compte tenu des évènements sociaux qui se sont produits lors de ce deuxième semestre, des priorités ont été fixées par rapport au cahier des charges initial. Il a été décidé lors de la réunion du 08/04/09 (compte rendu numéro 6) de concentrer le travail à faire sur les éléments les plus importants. Ainsi, les points suivants ont été retenus : La création de wiks La création d itinéraire Le mélange des deux (la sélection de wiks pour un itinéraire par exemple) La modération des itinéraires Création de scénarii de tests pour les itinéraires et les wiks Améliorer le listing des wiks et leur parcours Permettre la recherche d itinéraire Pour information, voici le cahier des charges initial fixé lors du premier semestre : Créer, modifier, supprimer, noter, consulter et commenter des wiks Créer, modifier, supprimer, noter, consulter et commenter des itinéraires Exporter les itinéraires pour un format GPS Afficher les itinéraires sous forme de trajet sur une carte o Capacité de zoom avec ajustement de la densité des wiks o Différenciation des itinéraires par des couleurs pour éviter la confusion o Affichage d'infos-bulles lors d'un clic sur un wiks Module de covoiturage o Recherche de passager o Recherche de conducteur o Recherche par taille de bagages acceptés, animaux de compagnie, prix, durée, émission de CO2, par type de voiture o Alerte par SMS Utilisateur représenté par un profil o Avatar o Statut (particulier, association,...) o Adresse o Numéro de téléphone Messagerie interne Possibilité de suggérer des idées de développement du site 3
Foire aux questions Moteur de recherche multicritère pour les itinéraires embarquant un algorithme de scoring en fonction des notes utilisateurs et de la pertinence des wiks 4
III. Fonctionnalités réalisées Hormis la modération des itinéraires, l ensemble des objectifs fixés lors de cette réunion a été atteint. Une modération au sens large (gestion des commentaires par exemple, suppression etc) n a pas pu être implémentée par manque de temps. Voici la liste de toutes les fonctionnalités implémentées sur l application wikiroute : (le cahier des charges initial étant assez exhaustif toutes n ont pas pu être implémentées) 1. Utilisateurs Le site internet permet aux internautes de s inscrire et d accéder à des fonctionnalités jusqu à lors inaccessibles. Les membres du site s enregistrent avec un statut précis : association, particulier etc. Une fois inscrit, certaines des informations fournies lors de l inscription du visiteur sont disponibles en consultation sur son profil. Les utilisateurs inscrits peuvent contribuer à alimenter le contenu du site internet. La première étape serait d enregistrer un maximum de wiks pour permettre leurs utilisations au travers de la création d itinéraire ou tout simplement leurs consultations de manière indépendante par les membres. D une manière générale, même si la messagerie interne n a pas pu être développée, le fait que le site internet propose l ajout de commentaires, les membres bénéficient tout de même d une certaine interactivité et d un retour positif ou négatif sur leurs contributions. 2. Wiks Les wiks sont un point clé pour cette application. L objectif étant le partage d itinéraire, un itinéraire ne sera intéressant que si son contenu l est. Les wiks permettent d enrichir les itinéraires et d encourager les membres à poster de bonnes informations, des informations utiles et pratiques qui feront le succès du projet. Afin de fournir cette matière première, nous avons mis à disposition des membres plusieurs fonctionnalités articulées autour des wiks. En premier lieu, leur création ; les membres peuvent créer des wiks de plusieurs façon. L interface de création est décomposée en deux parties. La première représente une carte sur laquelle le membre peut déposer un curseur pour matérialiser le lieu où il souhaite créer son wiks tandis que la deuxième partie permet à l utilisateur de saisir une adresse précise et de remplir les informations complémentaires (donner un titre, une description, classer sa contribution ). Cette partie a poussé la réflexion sur l ergonomie ; il a été difficile de pouvoir présenter un carte suffisamment grande pour être lisible et d associer en plus des champs de saisies. Actuellement, la solution adoptée est un système d onglets ; elle est pratique lors de la consultation du wiks créé ; en revanche une autre disposition pourrait être plus convaincante lors de la création. 5
Une fois le wiks créés, il est proposé à la communauté. Celle-ci peut l évaluer en attribuant une note de 1 à 5. Les wiks sont restitués sous forme de listing aux membres, ils peuvent visualiser leur titre ainsi que la note attribuée, ce qui leur permet de visualiser d un coup la «réputation» d un wiks. Lors de la consultation d un wiks, le membre peut aussi laisser un commentaire pour un remerciement, une suggestion ou autre. A noter aussi qu une recherche simple des wiks basée sur le titre et la description a été implémentée. 3. Itinéraires Une fois le site internet alimenté en wiks, les membres peuvent se lancer dans la création d itinéraire. Celle-ci se déroule en plusieurs étapes : lors de la première étape, le membre fournit une ville de départ et d arrivée ce après quoi le chemin le plus direct lui est tracé. Ensuite, libre à lui d ajouter des localités de passage des points de direction ou tout simplement de changer les paramètres d affichage pour lui permettre d afficher les Wiks disponibles autour de son itinéraire dans un rayon précis. Une fois son itinéraire créé, il peut être disponible pour les autres membres. Les membres peuvent y accéder via l outil Recherche itinéraire. Le membre peut aussi noter l itinéraire de 1 à 5 et laisser un commentaire dessus. 4. Généralités L application a été réalisée avec un langage à objet et un framework PHP. De ce fait, elle est facilement maintenable et personnalisable, tant au niveau des fonctionnalités qu au niveau de l apparence ; grâce à un système de layout, on peut facilement changer toute l apparence du site. Plus d informations sur la structure de l application dans la partie correspondante. 6
IV. Organisation 1. Trac Pour mener à bien le projet, nous avons mis en place des méthodes de travail et nous avons utilisé des outils pour nous aider. La première chose à faire était de gérer la répartition du travail. Nous avons utilisé à cet effet une application web dénommé TRAC (http://trac.edgewall.org/); cette application permet la gestion d un projet en créant les différentes tâches à réaliser en attribuant les tâches aux développeurs avec un suivi sous forme de ligne temporelle etc. 2. Subversion Deuxième problématique : comment travailler à deux sur un même projet? Parfois la répartition judicieuse des tâches ne suffit pas à exterminer toute source de conflit dans le code source ou autre. C est là qu intervient la technologie Subversion (SVN http://subversion.tigris.org). Subversion permet de versionner un fichier, c est-à-dire d attribuer un numéro de version à un fichier en fonction des nouvelles modifications apportées. Plus intéressant encore, SVN permet aussi de gérer un fichier manipulé par deux développeurs en même temps ; on utilisera alors la gestion de conflit. Au fur et à mesure du développement, les développeurs valident les nouvelles fonctionnalités en effectuant ce que l on appelle des «commits». Par exemple, lorsqu un nouveau développeur joint le projet et qu il souhaite récupérer les sources, il lui suffit de récupérer la dernier version du projet sur le dépôt SVN. Il pourra alors commencer à contribuer au développement lui aussi. 3. Netbeans & Eclipse Pour le développement en lui-même, nous avons utilisé des logiciels qui nous permettent d avoir une ergonomie de travail et d optimiser le temps de développement. Ces logiciels sont NetBeans (http://www.netbeans.org/) et Eclipse (http://www.eclipse.org). Les deux sont des environnements de développement offrant des fonctionnalités intéressantes. Parmi ces fonctionnalités, on retrouve notamment le plugin Subversion qui permet de greffer directement les fonctionnalités de subversion dans l environnement de développement. Concrètement, on peut, après avoir modifié une classe, rependre les changements d un simple clic. 4. FireBug FireBug est un addons pour le navigateur Firefox ; il nous a servi dans le projet à débugger la partie cliente en JavaScript. L application utilisant l API google Maps, il y a une énorme quantité de code JavaScript, un debugger était donc indispensable. FireBug permet de visualiser en détails l exécution du code coté client, de mettre des points d arrêt, d observer les requêtes http (pratique 7
pour le débuggage ajax) et de modifier le dom à la volée (pratique par exemple pour tester une modification légère rapidement sans avoir à toucher la mise en forme). 5. FirePHP FirePHP est aussi un addons pour le navigateur FireFox il se greffe à FireBug. Il permet à FireFox de recevoir des informations que le serveur lui envoie à partir du code source. Exemple : on peut recevoir des informations de profilage d une base de données ; pour cela, il suffit d activer FirePHP dans l arborescence Zend, il enverra alors au client toutes les requêtes SQL exécutées côté serveur directement dans la console FirePHP de l addons FireBug. 6. Planification Voici un extrait de la planification initiale, en gras toutes les parties réalisées : A Modéliser BDD 0.5 B Gestion inscriptions 1 C Creation WIKS 2.5 B D Création ITINERAIRE 4 B E Recherche Wiks 2 C F Recherche Itinéraire 4 D G Notation Wiks 1.5 C H Notation Itineraire 1.5 D I Modifier Wiks 1.5 C J Modifier Itinéraire 2 D K Modérer Wiks 1.5 C L Modérer Itinéraire 2 D 8
Méthode des potentiels METRA K 4 8.5 1,5 2.5 I 5.5 10 1,5 G 7 11.5 1,5 A 0 0 0.5 B 0.5 0.5 1 1 C 1.5 2.5 D 4 E 8.5 13 F 2 FIN 15 15 1.5 1.5 5.5 5.5 4 H 9.5 9.5 1,5 L Mustapha FODIL Valentin FAÏSSE Wikiroute 11 11 2 J 13 13 2 Figure 1 MPM Les tâches I J K L n ont pas pu être réalisées dans le temps imparti 9
V. Conception 1. Zend Framework Un site d importance se doit d être basé sur une architecture solide. Il y a donc 2 alternatives. La première consiste à créer sa propre architecture. Cette solution permet de concevoir une architecture correspondant au mieux aux besoins des développeurs et d être parfaitement assimilée par les personnes qui vont y travailler dessus. Les inconvénients sont qu elle nécessite beaucoup d expérience dans le domaine de l architecture logicielle et qu elle demande beaucoup de temps de réflexion, de conception et de tests. Pour ces inconvénients, nous avons opté pour la solution de facilité qui est d utiliser une architecture existante. Cette architecture est le framework Zend. Ce dernier est l une des solutions les plus abouties dans son domaine puisqu il a été conçu par les fondateurs de langage PHP. Il a aussi l avantage de posséder une grande communauté très active. Il est mis à jour régulièrement et a fait ses preuves avec de gros sites internet qui l utilisent. L inconvénient de cette solution pourrait être l assimilation du framework, mais grâce à sa très bonne documentation, communauté et extensibilité, quelques jours suffisent à l apprentissage de son fonctionnement et de sa configuration. Il profite aussi de partenariat avec de grandes entreprises comme Microsoft et Google qui lui permet d avoir des interfaces avec services web. De plus, sa conception sur le pattern MVC (Modèle, Vue, Controller) facilite le travail de groupe. 2. Arborescence L extensibilité de Zend Framework nous permet de créer une arborescence personnalisée mais sa configuration par défaut nous en propose une qui permet une mise en place rapide de ce dernier. Nous avons choisi de légèrement modifier cette arborescence qui est ci-contre. Le dossier library contient le framework Zend et les extensions dont nous avons besoin. Le dossier libray/wikiroute dispose de la même arborescence que le dossier library/zend pour nous faciliter la personnalisation du framework. En effet, la convention de nommage des classes Zend à été très bien pensée. Par exemple, la classe Zend_Http_Client_Adapter_Test se trouvera dans le fichier Zend/http/Client/Adapter/Test.php. Ce nommage offre l avantage, grâce à l autoload de Zend, de pouvoir instancier cette classe sans inclure manuellement le fichier. Donc, pour modifier le comportement de cette classe, il suffit d écrire la classe Wikiroute_Http_Client_Adapter_Test dans le fichier Wikiroute/http/Client/Adapter/Test.php. 10
3. Interface utilisateur Parce que de l interface utilisateur dépend le succès d un site, nous avons essayé de la rendre simple et ergonomique. Le premier problème était l utilisation d une carte géographique pour représenter les itinéraires. La carte devait afficher le plus d informations afin d améliorer la visibilité dans un design adapté à une petite résolution. Pour cela, nous avons choisi de ne mettre qu un seul menu à gauche et des raccourcis en dessous de l entête. Pour pallier l absence d un deuxième menu, nous avons rendu le menu de gauche déroulant pour qu il puisse afficher le plus d informations sans tenir trop de place. La création d un itinéraire n étant pas aisée de base, nous l avons facilité en divisant la procédure par étape où chaque étape doit être validée pour pouvoir passer à la suivante. Le principe est le même pour la création d un wiks. Concernant la consultation, nous avons réparti les informations par onglets pour une meilleure clarté. 4. Technologies Entre autre l utilisation du framework Zend, nous avons utilisé l API Google Maps et le framework JavaScript JQuery. L API Google Maps est un service gratuit de cartographie et de plan en ligne. Ce service permet de rechercher, de suivre ou créer des itinéraires. Utilisable en JavaScript, elle nécessite au préalable une inscription pour récupérer une clé et autorise jusqu'à 50000 interrogations par jour. Nous avons développé le site sur la version 2 de cette API, le passage à la version 3 a créé quelques modifications de comportement du site qui ont pu être corrigées. Cependant, nous n avons pas pu tester une nouvelle fois toute l application pour trouver d éventuelles modifications de comportement. Toutefois, le site de Google dédié aux développeurs utilisant l API assure avoir gardé une compatibilité avec les versions précédentes. Pour des soucis de compatibilité avec les différents navigateurs du marché et pour nous faciliter le travail en JavaScript, nous avons choisi d exploiter le framework JavaScript libre JQuery. Ce dernier propose des méthodes de manipulation de l arbre DOM, une gestion des requêtes AJAX et des évènements ainsi que des plugins graphiques, le tout compatible avec tous les navigateurs. Une multitude de ce type de Framework existe mais notre choix s est tourné vers celui-ci car nous avions déjà une expérience et qu il dispose d une bonne réputation. 11
VI. Tests Pour mener à bien nos procédures de tests, nous avons à notre disposition une multitude de techniques, chacune des techniques cible une utilisation précise. Le nombre de domaines à tester étant très important nous prendrons soin de choisir quoi tester précisément. Voici quelques points de réflexion et une liste des différents types de tests que l ont peut réaliser avec pour chacun/chacune des solutions pour les implémenter. 1. Analyse statique du code a. Responsabilités des classes, classes avec un trop grand nombre de méthodes b. Ambiguïté dans le nommage des variables, convention de nommages 2. Test dynamique a. Test des chemins possibles, toutes les pistes sont explorées? b. Chemin jamais pris = code inutile? c. Vérification des fonctions récursives 3. Tests unitaires a. Vérifier de manière plus ou moins atomique qu une série d instruction retourne un résultat attendu. b. Cela peut être effectué avec PHP Unit ou encore Zend Test 4. Montée en charge a. Apache benchmark est une commande proposée par le serveur apache qui permet de simuler des requêtes http vers une url précise, la commande analyse les temps de réponse et permet donc de déduire à partir de quand le serveur flanche. Evidemment, selon la solution technique utilisée et la manière de coder pour développer le site, le serveur ressentira des difficultés plus ou moins tôt. b. Jmeter, même principe qu apache benchmark, il propose en plus la possibilité de simuler une navigation de gérer les cookies (pour des login par exemple) 5. Tests de validation a. Les tests de validation sont une vérification des fonctionnalités livrées par rapport à celles exprimées ; on vérifie ici que le besoin a été satisfait dans une gestion de projet, cela revient à vérifier le respect du cahier des charges et des use case en génie logiciel 6. Sélection des tests à effectuer a. Impossible de tout tester b. Choisir les tests à effectuer c. Les sections critiques et importantes d. Visualiser la couverture des tests, à savoir le pourcentage de code testé Analyser les résultats des tests 1. Interprétation des résultats 2. Lecture des résultats : Survol pour repérer rapidement les défaillances, via par exemple les graphes de contrôles, que peut fournir un logiciel tels que logiscope 12
Extras : Les tests étant très importants pour une application (souvent la durée des tests dépasse celle du développement), il faut communiquer l importance des tests à l initiateur du projet (le client). Pour le client, les tests n apportent pas de fonctionnalités supplémentaires et n ont donc pour lui aucune valeur ajoutée. VII. Mise en pratique 1. Quoi tester? Beaucoup d outils de test existent et on serait tenté de tous les faire mais suivant l objectif de l application, certains tests seraient une perte de temps de les effectuer. Dans le cadre de notre application, nous avons choisi d utiliser 4 outils différents qui sont : PHP_CodeSniffer, PHP_SecAudit, PHP_Depend et PHP_Unit. PHP_CodeSniffer est un script php5 qui analyse les code PHP et JavaScript pour détecter les violations d'un ensemble de règles de codage définies. C'est un outil de développement essentiel qui assure que le code reste propre et consistant. Il peut même aussi prévenir de certaines erreurs de sémantique commises par les développeurs. PHP_SecAudit est un outil d analyse de sécurité du code PHP. Il permet de mettre en évidence des failles potentielles dans un script comme les variables GET ou POST qui n auraient pas été «sécurisées» avant leur utilisation. PHP_Depend est un outil d'analyse statistique qui permet de cartographier les dépendances entre les différents packages de classes composant une application. Il utilise pour cela 4 métriques lui permettant de générer un graphique qui permet une lecture rapide du niveau d'instabilité et d'abstraction du code considéré. PHP_Unit est un outil permettant de faire des tests unitaires. Le framework Zend offre des classes permettant de faciliter l implémentation des tests unitaires avec l outil PHP_Unit. Ce dernier permet de reproduire des requêtes http semblables au requêtes http qu enverrait un visiteur. 2. Comment tester? 1. PHP_CodeSniffer : Utilisé en ligne de commande (phpcs), il génère un résultat sur la console ou dans des fichiers pour l analyse d un ou plusieurs fichiers ou dossiers. 13
Figure 2 : Résultat de l'analyse du controller membre La commande phpcs dispose de plusieurs options, entre autre de choisir le standard à utiliser (PEAR, Zend, Squiz, ), le type de rapport à générer (xml, summary, full, ). 2. PHP_SecAudit : C est un dossier comprenant un ensemble fichier PHP devant être appelé avec la commande «php www/phpsecaudit/run.php». Peu d options sont disponibles mais le résultat généré sont des fichiers html détaillant le résultat du dossier analysé. Figure 3 : Résultat html issu de l'analyse 3. PHP_Depend : Utilisable en ligne de commande, il ne propose pas d option mis à part la spécification du dossier à analyser et la destination des 3 fichiers à générer. Voilà un exemple de commande : «pdepend --summary-xml=/tmp/summary.xml --jdepend-chart=/tmp/jdepend.svg --overviewpyramid=/tmp/pyramid.svg /usr/local/share/pear/php/depend» Cette commande génèrera 3 fichiers dont 2 graphiques. Le premier graphique sera un nuage de points représentant le niveau d abstraction et d instabilité de l application. Le deuxième graphique sera le calcul de métrique comme la complexité cyclomatique 1, le nombre de lignes de code, de méthodes, de classes ou de package. 1 Cette mesure comptabilise le nombre de «chemins» au travers d'un programme 14 Figure 4 : Listes des métriques Figure 5 : Niveau d'abstraction et d'instabilité des classes
Les classes (cercle) présentes sur la ligne verte signifient que la formule liant la stabilité de la classe et son niveau d abstraction la rendent équilibrée. Légende listes des métriques extraite du site de l auteur : *Ca* - Afferent Couplings: The number of other packages that depend upon classes within this package. This value is good indicator how changes to classes in this package would influence other parts of the software. *Ce* - Efferent Couplings: The number of other packages that classes from this package depend upon. This value indicates how sensitive this package is for changes to other packages. *I* - Instability: The ratio between efferent coupling (Ce) and the total package coupling (Ce + Ca) which is based on the following formula (Ce / (Ce + Ca)) and produces results in the range [0,1]. A value I=0 indicates a maximally stable package that depends upon nothing and I=1 indicates a total instable package that has no incoming dependencies but depends upon other packages. *A* - Abstractness: The ratio between abstract classes (ac) and the total of all classes (ac + cc) that is calculated by this formula (ac / (ac + cc)) that results in a value in the range [0,1]. A=0 means that all classes in this package are non-abstract while A=1 shows a package that only consists of abstract classes and interfaces. 4. PHPUnit Pour exécuter les tests PHPUnit, il nous faut trois fichiers : Le premier fichier est la réalisation des différents tests et assertions : 15
Figure 6 tests et assertions On simule dans notre test l inscription d un membre. 16
Le deuxième fichier est un fichier php qui sera lancé par la phpunit ; c est un sorte de controlleur frontal : Enfin la dernière partie l exécution du test : Figure 7 Controller PHPUNIT Figure 8: Résultat analyse PHPUnit On voit ici le que le test a échoué lors du test de redirection. Normalement, lorsqu un membre s inscrit, il est redirigé vers l accueil ; cette redirection fonctionne en test manuel mais pas avec les tests unitaires. Cette incohérence semble liée à la méthode de redirection. 17
3. Bonus : Apache benchmark permet de tester la montée en charge des serveurs ; ainsi nous essayons d appeler la page d accueil du site dans un nombre d itérations contrôlées de cette manière : i. ab n 100 http://r16221.ovh.net/wikiroute/accueil/index Figure 9 bench mark results On voit sur le test apache que 100 requêtes http ont été satisfaites en 17sec par exemple. On voit aussi que lors des dernières requêtes le temps de réponse augmente considérablement passant de 257ms à 493ms : c est là que l expression «montée en charge» est justifiée. 18
VIII. Ouvertures 1. Alternative A La première alternative que l ont peut proposer pour la réalisation du projet wikiroute aurait été de le réaliser avec un autre framework. Sur le marché, la concurrence est rude et le style de développement peut être très varié d un framework à un autre. Comme concurrent, on retrouvera : QCubed (http://qcu.be), Symfony, Jelix (très inspiré par symfony), CakePHP, etc. Tous ces outils ont des plus et des moins, mais bien souvent le meilleur framework est celui que l on maîtrise. 2. Alternative B Nous pourrions aussi faire le site de manière très interactive en utilisant à outrance le javascript, incrusté des systèmes de blocs (façon Net Vibes http://www.netvibes.fr), le tout en ajax avec un seul chargement initial. Le trafic réseau n aurait été que du texte grâce à JSON. IX. Conclusion Le projet wikiroute a été bénéfique pour cette première année de master, il nous a obligé à nous organiser d un point de vue méthode de travail. En effet, avant ce projet, nous n avions pas d idée sur concrètement comment faire travailler plusieurs développeurs sur un même projet. Il nous a permis de découvrir Subversion, Trac et aussi de nous initier au Framework Zend qui est un des plus répandus. Nous avons maintenant une routine de travail que nous avons mise en place dans nos habitudes de développement au-delà du projet wikiroute. Nous utilisons maintenant Subversion et Trac à outrance (mais avec modération tout de même). D un point de vue gestion de projet, wikiroute était initialement prévu avec un bon nombre de fonctionnalités. Il est vrai que le développement n est pas arrivé à son terme, il n en reste pas moins que nous pouvons aujourd hui proposer sur le site des fonctionnalités minimales qui permettent son fonctionnement. Cependant, on prendra soin de réaliser toutes les différentes parties relatives à la modération avant de mettre l application en production. 19