doc - Université d'Avignon

mustardunfInternet και Εφαρμογές Web

21 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

150 εμφανίσεις



IUP GMI


Master 1ere année


09

Projet Wikiroute


Etudiants

:
Mustapha FODIL


Valentin FAÏSSE
Tuteurs : Corinne FREDOUILLE, Frédéric DUVERT




2



I.

Récapitulatif S1

................................
................................
................................
....................

3

II.

Fonctionnalités à réaliser

................................
................................
................................
....

3

III.

Fonct
ionnalités réalisées

................................
................................
................................
.....

5

1.

Utilisateurs

................................
................................
................................
......................

5

2.

Wiks

................................
................................
................................
................................
.

5

3.

Itinéraire
s

................................
................................
................................
........................

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



3


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 wik
iroute.

G
lobalement
,

le projet consiste en la création d’un site internet où les différents
visiteurs peuvent s’inscrire et partager leur
s

connaissances de la géographie (création d’
itinéraire
) et
des bonnes adresses (création de wiks) où l’on peut bénéfic
ier d’
avantages quelcon
ques
.

II.

Fonctionnalités à réaliser

Compte tenu des évènement
s

sociaux qui se s
ont produits lors de ce deuxièm
e semestre, des
priorités ont été fixé
es

par rapport au cahier des charge
s

initial.

Il a été décidé lors de la réunion du 08/0
4/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 parcour
s



Permettre la recherche d’itinéraire

Pour information, voici le cahier des charges initial fixé lors du prem
ier 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 i
tinéraires sous forme de trajet

sur une ca
rte

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

Re
cherche 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



4




Foire aux questions



Moteur de recherche multicritère pour les itinéraire
s

embarquant un algorithme de
scoring en fonction des notes utilisateurs et de la pertinence des wiks



5


III.

Fonctionnalités réali
sé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 li
ste de toutes les fonctionnalités implémenté
e
s 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
inaccessible
s
. Les membres du site
s’enregistrent

avec un statut précis

:

association,
p
articulier etc. Une fois inscrit,

certaines des informations fournies lors de l’inscription du visiteur
sont disponible
s

en consultation s
ur son profil
.

Le
s 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
leur
s consultations

de manière indépendante
par les

membres
.

D’une manière générale
,

même si la messagerie in
terne n’a pas pu être développée
, le fait
que le site internet propose l’ajout de commentaire
s
,
les membres bénéficie
nt

tout de même d’une
certaine int
eractivité 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’enrich
ir les itinéraires et
d’encourager les membres à poster de bonnes informations, des informations utiles et pratique
s

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é
e
s autour des wiks
. En premier lieu
,

leur création

; les mem
bres peuvent créer
des wiks de plusieurs façon. L
’interface de création est décomposé
e

en deux partie
s. La première
représente
une carte sur laquelle le membre peut déposer un curseur pou
r matérialiser le lieu où i
l
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 part
ie a poussé la réflexion sur l’ergonomi
e

;

il a été difficile de
pouvoir
présenter un carte suffisa
m
ment grande pour être lisible et d’associer en plus des champs de saisies.

Actuellement
,

la solution adopté
e

est un système d’onglet
s

;

elle est pratique lo
rs de la consult
ation
du wiks créé

;
en revanche
une autre disposition pourrait être plus convaincante lors de la création
.



6


Une fois le wiks créé
s,

il est proposé à la communauté. C
elle
-
ci peut l’évaluer en attribuant
une note de 1 à 5. Les wiks sont
rest
itué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 c
oup la «

réputation

» d’un
wiks.

Lors de la consultation d’un wiks
,

le membre pe
ut aussi laisser un commentaire

pour un
remerciement
,

une suggestion ou autre.


A noter
aussi
qu’un
e

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 u
ne
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 perme
t
tre d’afficher les Wiks disponible
s

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 membre
s

peuvent y accéder via l’outil

‘R
echerche 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 fonctionnali
té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
corre
spondante
.



7


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 temporel
le

etc
.

2.

Subversion

Deuxième problématique

:

comment travailler à deux sur un même proj
et

? P
arfois la
répartition

judic
ieuse des tâches ne suffit pas à

exterminer tout
e

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 pe
rmet aus
si 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 valide
nt

les nouvelles fonctionnalités
en effectuant ce que l’
on appel
le

des
«

co
m
mit
s

»
.
Par exemple, l
orsqu’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 versi
on du
projet sur le dépôt SVN. I
l pourra alors commencer à contribuer au développement lui
aussi
.


3.

Net
bea
ns & Eclipse

Pour le développement en lui
-
même, nous avons utilisé des logiciels qui nous permette
nt

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.ec
lipse.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’envir
onnement de développement.
Concrètement
, on peut,
après avoir modifié une classe
,

rependre

les changements d’un simple cli
c
.

4.

FireBug

FireBug est un addons pour le navigateur
Firefox

;

il nous a servi dans le projet à débugger la
partie cliente en
JavaScrip
t
.
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é clien
t, de mettre des points d’arrêt,

d’observer les requête
s http (pratique


8


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 gref
fe à FireBug. I
l 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 Ze
nd
,

il enverra alors au client toutes les requêtes SQL
exécutées



serveur directement dan
s

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

Mo
dérer Itinéraire

2

D



9




Figure
1

MPM

Les tâches I J K L n’ont pas pu être
réalisées

dans le temps imparti



10


V.

Conception

1.


Zend Framework

Un site d’importance s
e doit d’être basé sur une architecture solide. Il y a donc 2 alterna
tives.
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
test
s
.

Pour ces inconvénients
,

nous avons opté pour la solution de facilité qui est d’u
tiliser une
architecture existante. Cette architecture est le framework Zend. Ce dernier est l’une des solutions
les plus aboutie
s

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 commun
auté 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
extensi
bilité
,

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 conc
eption sur le pattern MVC
(Modèle, Vue, C
ontroller) facilite le travail

de groupe.


2.


Arborescence

L’extens
ibilité 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 d
e ce
dernier. Nous avons choisi

de légèrement modifi
er

cette arborescence qui est ci
-
con
tre.

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 conventi
on 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.




11


3.



Interface utilisateur

Parce qu
e 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’informatio
n
s 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 men
u 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

pass
e
r

à la suivante. Le principe
e
s
t 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, l
e passage
à la version 3 a créé

quelques modifications de comportement du site qui ont pu être
corrigé
es
. Ce
pendant, 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
p
récédentes.

Pour des soucis de compatibilité avec les différents navigateurs du marché et po
ur
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 graphiqu
es, 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 ex
périence et qu’il dispose d’une bonne
réputation
.



12


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 prendr
ons

soin de choisir quoi tester précisément.


Voici quelques points de réflexion et une liste des différents type
s

de tests que l’ont
peut réaliser avec pour chacun/chacune des solutions pour les implémenter.

1.

Analyse statique du code

a.

R
esponsabilités des classes, classes avec un trop grand nombre de méthode
s

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ér
ification des fonctions récursives

3.

Test
s

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 comm
ande proposé
e

par le serveur apache qui permet
de simuler des requête
s

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 l
a 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.

T
ests de validation

a.

Les tests de validation sont une vérification des fonctionnalités livré
e
s par rapport à
celles exprimé
e
s

;

on vérifie ici que le besoin a été satis
fait 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

:

S
urvol
pour repérer

r
apidement les défaillances,

via par exemple les
graphe
s

de contrôles, que peut fournir un logiciel tels que logiscope



13


Extras

:

Les tests étant très importants pour une ap
plication
(
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
aucu
ne valeur ajouté
e.

VII.

Mise en pratique

1.


Quoi tester

?

Beaucoup d’outils de test existent et on sera
it 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
applica
tion
,

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 le
s

code PHP et JavaScript pour détecter les
violations d'un ensemble de règles de codag
e 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 P
HP. 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épendan
ces
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’enverrai
t

un v
isiteur.

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.



14



Figure
2

: Résultat de l'analyse d
u controller membre

La commande phpcs dispose de plusieurs options, en
tre 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 P
HP devant être appelé avec la commande
«

php www/PhpSecAudit/run.php

». Peu d’option
s

sont disponible
s

mais le résultat généré sont des
fichier
s

html détaillant le résultat du dossier analysé.


Figure
3

: Résultat html issu de l'a
nalyse

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
--
overview
-
pyramid=/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’app
lication. 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


Figure
5

: Niveau d'abstraction et d'instabilité des classes



Figure
4

: Listes des métriques




15


Les classes (cercle) présent
es

sur la ligne verte signifient que la formule liant la stab
ilité de la
classe et son niveau d’abstraction la rende
nt

équilibré
e.

Légende listes des métriques extraite du site de l’auteur

:

*Ca*
-

Afferent Couplings:

The number of other packages that de
pend upon classes within this
package. This value is
good ind
icator h
ow 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 sensitiv
e this package is for change
s
to other

packages.


*I*
-

Instability:

The ratio between efferent coupli
ng (Ce) and the total package coupling (Ce + Ca)
which is
based on the following formula (Ce / (Ce

+ Ca)) and produce
s 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
classe
s 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 l
es tests
PHPU
nit
,

il nous faut trois fichiers :

Le premier fichier est la réalisation des différents tests et assertions

:



16



Figure
6

tests et assertions


On simule dans notre test l’inscription d’un membre
.








17



Le deuxième fich
ier est un fichier php qui sera lanc
é

par la phpunit

;

c’est un sorte de
controlleur frontal

:


Figure
7

Controller PHPUNIT

Enfin la dern
ière partie l’exécution du test

:


Figure
8
: Résultat analyse PHP
Unit

On voit ici le que le test a

échoué lors du test

de redirection. N
ormalement
,

lorsqu’un
membre s’inscri
t,

il es
t redirigé vers l’accueil

;

cette redirection fonctionne en test manuel mais pas
avec les tests unitaire
s
. Cette incohérence semble lié
e

à l
a méthode de redirection.



18


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 da
ns 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 der
nières requêtes le t
emps de réponse augmente considé
rablement
passant de
257ms à 493
ms

:

c’est là que l’expression
«

montée en charge

»

est justifiée
.




19


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
. C
omme concurrent
, on retrouver
a

:
QCubed (
http://qc
u.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
qu
e l
’on maîtrise
.

2.


Alternative B

Nous pourrions aussi faire
le s
ite de manière très interactive

e
n utilisant à outrance le
javascript, incrusté des systèmes de blocs (façon
N
et
V
ibes
http://www.netvibes.fr
)
,

le tout en ajax
avec un seu
l

chargement initial
. Le tra
fic réseau n’aurait été que du
texte grâce à JSON.

IX.

Co
nclusion

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 travaill
er

plusie
urs développeurs sur un même projet. Il nous a permis de découvrir Subversion
, Trac

et aussi
de nous initi
er

au Framework Zend
qui
est un des plus répandu
s
.

Nous avons maintenant une routine de travail que nous avons mis
e

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 vra
i 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
pa
rties relatives à la modération avant de mettre l’application en production
.