2015 TD3 FR Moodress

Documentation technique
L’équipe Moodress :
tchiko_s bonet_g thiec_a ozkul_o pica_d

(Chef de groupe)
pons_c thomas_t labell_s


Résumé :
Ce document décrit l’intégralité de l’architecture du projet Moodress. Notre

projet étant à la base un serveur utilisant Symfony et Doctrine pour créer notre base
de données. Notre API permet ensuite à nos applications mobiles et notre site web de
communiquer avec le serveur et avoir un accès indirect à la base de données. Nous
utilisons pour réaliser notre solution le framework PHP Symfony2, l’ORM Doctrine pour
la gestion de notre base de données et enfin Cordova (PhoneGap) pour développer les
applications mobiles. Nous utilisons essentiellement Github pour gérer le code de
notre projet et les tâches en cours de réalisation.
2015_TD3_FR_Moodress.pdf


Tableau de révision :
Date Auteur Commentaire
24/02 – 16/03 Sandro Tchikovani Préparation du document, mise en page,

corrections.
05/03 - 09/03 Steeven Labelle Les choix techniques
08/03 - 14/03 Arnaud Thomas Elaboration de plan pour la partie Réalisation.

Dessessarts Rédaction partie User, Notifications, Tag /
Fashtags, Follower / Following, Interfaces
utilisateurs. Elaboration de nouveaux schémas
via l’outil Visio.
08/03 - 14/03 Alan Thiec Elaboration de plan pour la partie Réalisation.

Rédaction des parties Postes, Albums,
Commentaires, Like, Search, Statistics.
08/03 – 13/03 Omer Ozkul Partie architecture.
11/03 – 12/03 Guillaume Bonet Fixation de bugs
11/03 - 11/03 Thomas Tortorini Corrections
14/03 – 14/03 Dany Pica Corrections
03/07 - 03/07 Guillaume Rajout de la partie mobile
03/07 - 03/07 Arnaud Mise à jour par rapport à la version actuelle de

notre produit
03/07 - 03/07 Alan Modification de la partie Module

Modification de la partie Interface Utilisateur
04/07 – 04/07 Sandro Mise en page
02/10 - 05/10 Sandro,Dany,Omer Révision intégral du document, Mise en page


Sommaire
1) Contexte ........................................................................................ 1

2) Architecture .................................................................................... 1
A) « Use case » de notre architecture ................................................................. 1
B) Diagramme global de solution ........................................................................ 6
C) Diagramme des entités ................................................................................. 8

3) Choix techniques ............................................................................. 10
4) Modules......................................................................................... 12
A) API.........................................................................................................12
B) Serveur ...................................................................................................16
C) Mobile ....................................................................................................18
a) Hiérarchisation ......................................................................................18
b) Déploiement..........................................................................................19
c) Test de l’application ................................................................................20
d) Débuggage ............................................................................................20
D) Base de données .......................................................................................20
a) User ....................................................................................................20
b) Post/Album/Commentaires ........................................................................21
c) Like .....................................................................................................22
d) Notification ...........................................................................................22
e) Tags / Fashtags.......................................................................................22
f) Follower / Following ................................................................................22
g) Fashthème ............................................................................................23
h) Report .................................................................................................23
i) Up/Premium ...........................................................................................23

5) Fixation de bug ............................................................................... 23


1) Contexte
L' « École pour l'informatique et les nouvelles technologies » ou EPITECH, est

une école formant des experts en informatique sur cinq années. Elle dispose d’une
pédagogie particulière. En effet sur chaque projet les étudiants sont impliqués dans
leur apprentissage et peuvent donc s’adapter aisément aux contraintes des projets
demandés par l’école et aussi, par exemple aux évolutions technologiques qui auront
lieu au cours de leur carrière.
L’ « EPITECH Innovative Project » ou EIP, est la principale étape dans le cursus

de l’école. C’est un projet de fin d’études réunissant au minimum six étudiants. L’EIP
se déroule sur une durée de trois ans, une durée bien plus importante que celle des
projets en début de cursus. L’EIP est crucial dans le cursus car elle change le statut
d’étudiant à celui de professionnel.
2) Architecture
A) « Use case » de notre architecture
Les cas d’utilisations suivants représentent les actions que peut réaliser le
client. Ces diagrammes permettent de mettre en action notre architecture dans des
scénarios qu’un utilisateur lambda pourrait rencontrer.
Le cas d’utilisation de la barre de navigation est l’élément principal que

rencontrera chaque utilisateur connecté (ou non connecté). Elle est présente sur
chaque page afin de permettre à l'utilisateur d'avoir accès à tout le site via une
simple interface.
Elle permet de lier chaque élément de notre site mais permet également la création
de publications, et l'affichage des notifications reçus par l'utilisateur.
Voir le cas d’utilisation à la page suivante
2015_TD3_FR_Moodress.pdf 1
Cas d’utilisation de la barre de navigation
Un autre élément visible par tous les utilisateurs et présenté via ce cas
d’utilisation est la page d’accueil. C’est la page principale de notre réseau social qui
permettra aux utilisateurs connectés (ou non connectés) de découvrir les nouvelles
tendances créées par la communauté Moodress.
La page d'accueil affiche les derniers articles sur le fil d'actualités et les
dernières publications mises en avant via la bannière défilante. Il est possible de
spécifier l'affichage des publications que l'on souhaite via les filtres présents sous la
bannière défilante.
Cas d’utilisation de la page d’accueil
Les publications sont les éléments principaux de notre réseau social. Elles
permettent de partager un style aux autres utilisateurs.
Il est possible d'intégrer 1 à 7 images mais également une description (dans laquelle
on peut nommer d'autres utilisateurs et des fashtags).
Cette publication sera ensuite vue par les autres utilisateurs qui pourront commenter
et aimer cette publication.
Voir le cas d’utilisation de la vue détaillée d’une publication à la page suivante
Cas d’utilisation de la vue détaillée d’une publication
Sur la page profil il est possible à l'utilisateur de voir ses publications ainsi que les
personnes qu'il suit ou qui le suivent. Il peut gérer ses albums (créer/supprimer un
album ou ajouter/supprimer des images). Cette page permet à l'utilisateur de
récapituler toutes les actions qu'il a pu réaliser sur le réseau social.
Cas d’utilisation de la page profil
La page des paramètres permet de modifier les éléments principaux de votre

compte (nom, prénom, mail, photo de profil, ...).
Elle offre la possibilité de devenir premium afin de donner la possibilité à l’utilisateur
de promouvoir leurs publications pour qu'elles apparaissent sur la bannière défilante
de la page d'accueil.
Il est également possible de faire une demande afin de devenir une page marque pour
les créateurs indépendants ou les entreprises. Cette dernière permet d'avoir un
affichage différent afin d'être plus facilement reconnaissable au sein de la
communauté.
On permet aussi la possibilité de supprimer son compte via cette page.
Cas d’utilisation de la page paramètre
La page d'administrateur permet aux administrateurs d'analyser l'activité du réseau

social.
Il offrira la possibilité de gérer les utilisateurs ainsi que les pages marque mais
également la création de jeux à thème.
Cette partie permet donc de récupérer des statistiques de notre réseau social et de
gérer son contenu.
Voir le cas d’utilisation de la page administrateur à la page suivante
Cas d’utilisation de la page administrateur
B) Diagramme global de notre solution
L’architecture d’un site et plus généralement d’un projet informatique correspond

à l’ensemble des choix techniques qui structurent le projet : modèle de conception
(« design pattern », lié au « framework » choisi), choix et définition de la base de
données, choix du langage de programmation et aussi mais surtout la structure
générale du site (telle que nous la définissons, à savoir par exemple les interactions
entre les différentes fonctionnalités / modules du site).
Ces éléments définissent le « squelette » général de ce que sera notre projet. Il

est primordial de choisir correctement ces différentes composantes de notre site pour
plusieurs raisons :
• Temps de développement du projet

En effet si les choix en termes d’architecture ne sont pas judicieusement faits
et ne sont pas adaptés, le temps de développement peut s’en voir fortement
impacté.
• Capacité d’évolution du projet
Notre site étant un réseau social, il est plus que n’importe quel autre site
amené à évoluer, rapidement et régulièrement. Si l’architecture générale du
site n’est pas pensée pour être assez flexible / évolutive, cela peut poser de
sérieux problèmes sur la durée. Ces problèmes peuvent être l’augmentation de
la durée des développements ou même une restructuration partielle ou
complète du site.
• Performances
Bien que nous n’ayons pour le moment pas l’ambition / la prétention d’être le
nouveau Facebook, l’architecture générale du site se doit cependant d’être
également synonyme de performances. Il ne s’agit pas ici d’orienter le langage
de programmation vers du très bas niveau (C / C++ / ASM...etc.) car cela n’a
en l’état actuel du projet aucun sens. Notre objectif est de produire un site
fluide et agréable à utiliser (le choix du framework, de la base de données et la
structure générale du site jouant un rôle primordial).
L’architecture de notre projet sera basée sur le modèle n-tiers avec 3 couches
distinctes :
• La base de données
• Le serveur web
• Le client (web ou mobile)
La base de données est le cœur de notre projet. Cette partie contiendra toutes
les données essentielles à notre site web. Cette base de donnée est générée via l’ORM
(Object-relational mapping) Doctrine. Cet ORM permet de convertir les entités
Symfony en base de données orientée objet.
Elle sera en liaison avec la partie Serveur web qui interagira avec ses données. Seule
la partie Serveur web aura la possibilité de communiquer avec la base de données.
Le serveur assure la transmission des vues et des données pour les navigateurs. Elle
comprend des web services pour chaque fonctionnalité.
La partie mobile est réalisée avec phoneGap, ce sont donc des applications web qui
auront pour utilité d’afficher les éléments reçus par le serveur.
Voir le schéma de l’architecture globale à la page suivante
Schéma de l’architecture globale
C) Diagramme des entités
Notre projet est divisé en différentes couches qui seront décrites dans cette
partie afin de donner une vision globale du rendu final.
Les classes de la couche base de données ne sont qu’une représentation des
différentes tables. Ces tables représentent l’architecture de notre base de données.
Sur ce diagramme de classe nous observons la structure de notre base de
donnée.
Voir le diagramme de classe de la base de données à la page suivante
Diagramme de classe de la base de données
Sur ce diagramme on retrouve une table "users" dans laquelle on stocke les
informations liées à l'utilisateur (nom, prénom, mail, albums, ...).
Une table "likes" qui contient l'id de l'utilisateur qui a aimé (une
publication/image/commentaire/album/...) ainsi qu'un "id_object" de l'objet
concerné par cet élément et son type pour le différencier.
Une table "postes" qui représente les publications réalisées sur notre site dont
dépendent deux autres tables, "poste_fashtag" pour les fashtags se trouvant dans la
déscription et "poste_pictures" qui contient les images de la publication.
La table "up" concerne les publications mises en avant. Le "fastheme" concerne les
jeux du moment crée par un administrateur afin de faire interagir les utilisateurs sur
un thème précis sur un temps imparti.
Le "report" est la gestion des retours utilisateur sur notre site mais également les
retours sur les commentaires ou images inappropriées.
3) Choix techniques
Symfony 2
Notre choix pour Symfony2 s'est fait grâce à plusieurs facteurs:
1. L'équipe de développement est composée d'une majorité de personnes ayant

déjà pratiqué du PHP. Le seul challenge pour ces personnes fût d'appréhender
le framework.
2. Nous voulions un framework qui gère la base de données à partir de sa propre
ORM (Ici, Doctrine).
3. Le fait que Symfony2 soit MVC n'a fait que confirmer notre choix. Cette
architecture basée sur la forte cohésion et le faible couplage nous permet de
manier les changements plus facilement. Les vues sont effectuées dans des
twigs, très puissant pour afficher des données dynamique et pour effectuer
certaines actions faisant partie de la logique quand c’est nécessaire.
4. Le fait que Symfony2 soit facilement testable grâce à PHPUnit, nous pouvons
faire une application de qualité, totalement automatisée. Les tests
d'intégrations et unitaires étant un bien non négligeable sur la robustesse du
produit, nous mettons tous nos efforts pour ne pas laisser de côté la partie
qualité du projet.

jQuery
jQuery est très puissant et nous permet de rendre le site plus attractif en le rendant
dynamique via les animations mais aussi grâce à l’envoie et la récupération de
données. On évite de recharger les pages dans certains cas grâces aux appels Ajax.
Foundation CSS

Ce framework nous permet de gagner beaucoup de temps dans la réalisation des
styles pour nos pages. Le framework est très complet, et il génère automatiquement
du code CSS qui est responsive.

Cordova (PhoneGap)

Nous voulions au début faire une application mobile native sous Apple,
Windows Phone et Android (respectivement en ObjectiveC, C#, Java).
Malheureusement, à cause de notre retard, nous avons dû mettre en place un plan de
redressement pour notre projet. Nous avons donc choisis Cordova pour le
développement d'une application hybride. Cordova offre tous les fonctionnalités

natives et permet le cross-plateforme.
Cordova nous permet donc de créer des applications mobiles natives seulement
en développant avec du HTML/CSS/Javascript. C’est le compilateur de Cordova qui
génèrera les applications sous iOS, Android et Windows Phone dans leurs languages
respectifs. Nous utilisons aussi le framework Ionic qui est un framework HTML5/CSS3,
il nous permet d’avoir déjà des éléments de base (boutons, modal, formulaires etc.)
implémentés et qui s’adapte correctement sur les différentes plates-formes mobiles.
Github
Nous utilisons les bienfaits de git et du service d'hébergement GitHub pour

notre projet. Nous fonctionnons par issues et pull requests. Les pull requests forcent
les développeurs à voir le travail de toute l’équipe. Les collaborateurs sont libres de
donner leurs critiques et commentaires. S’il n’y a aucune amélioration à apporter,
nous procédons au merge. Si nous estimons que le code n'est pas robuste, clair ou que
nous détectons du code mort, le développeur se doit de modifier son travail pour que
sa pull request soit acceptée.
Les issues peuvent être créées par n'importe quel développeur et être assignées à
n'importe quel autre.

Plusieurs labels sont présents pour faciliter la gestion de ces issues :

• Tâche du lab EIP: On répertorie les tickets liés à une interaction directe avec
les serveurs du laboratoire, mais aussi pour les mises à jour du site vitrine
disponible sur http://eip.epitech.eu/2015/moodress.
• Bugs: la partie résolution et amélioration des incidents rencontrés est
disponible dans ce label. Le ticket est fermé seulement si une solution est
rencontrée pour la correction du bug.
• Feature: Ici seront présentes les différentes branches nécessaire à la
réalisation du projet, ainsi que le système de pull-request qui sera détaillé plus
en profondeur plus loin dans le document.
• Questions: Les différentes questions que possèdent les membres du groupe en
lien avec le projet, ou avec le Lab EIP lors des suivis.
• Mises à jour: Les différentes parties implémentées ne sont pas toujours
pleinement fonctionnelle ou alors certaines parties peuvent être plus
générique. C’est donc ici que se retrouveront toutes les mises à jour du projet.
• Design: L’ergonomie et l’interface de notre site en matière de design sera
directement géré via ce label.
• Mobile: La partie pour les différentes applications mobile et la partie design
pour adapter aux écrans des smartphones, tablettes, seront disponibles dans
cette catégorie.
• Tests: Si des bundles ou des librairies doivent être testées pour une éventuelle
implémentation dans le projet, ils seront répertoriés ici.
4) Modules
A) API
Dans cette partie, nous vous exposons les différents modules de l’API ainsi que les
différentes actions disponibles pour chacun des modules. Pour connaître les détails de
chaque méthode, vous pouvez consulter la documentation complète disponible sur
ce lien.
Vous pourrez connaître la méthode HTTP utilisée, les paramètres requis et optionnels,
un exemple d’appel ainsi que la réponse renvoyée.

Les utilisateurs
Plusieurs actions sont possibles pour gérer les utilisateurs depuis l’API.
• Création de compte : Les clients peuvent créer un nouveau compte. Il suffit de

transmettre en paramètre les champs obligatoires comme le pseudo, l’adresse
email, le password etc.
• Vérification de la disponibilité du pseudo : Cette méthode permet d’informer
l’utilisateur si le pseudo qu’il rentre dans le champs est déjà utilisé.
• La connexion : Pour se connecter, on a juste besoin de transmettre en
paramètre un pseudo et un mot de passe.
• Modification de compte : Il est possible de changer certains paramètres du
compte. Cela peut-être des données du profil (édition du pseudo, le pays, ou le
username), ou bien encore des paramètres de confidentialité (Mettre son
compte en privée).
• Modification de mot de passe : Une méthode a été spécialement créer pour
l’édition du mot de passe. Il suffit de transmettre en paramètre l’ancien mot
de passe, le nouveau, ainsi que sa vérification.
• Déconnexion : Cette méthode permet de se déconnecter. Elle ne nécessite
aucun paramètre.
• Suppression de compte : Tout comme la déconnexion, cette méthode nécessite
aucun paramètres, il faut juste que la partie client s’assure de demander une
confirmation à l’utilisateur.
Les pages marques
• Effectuer une demande pour devenir une page marque : Cette action ne
requiert aucun paramètre. Cela va juste créer une demande qui devra être
validée dans la partie administration du site.
• Effectuer la transformation en page marque : Cette méthode sera accessible
uniquement pour les utilisateurs ayant le rôle d’administrateur. Si la requête
est acceptée, on appelle cette méthode en transmettant uniquement un
identifiant utilisateur.
• Retrait du statut “Page Marque” : Côté administration, il doit être possible de
retirer ce statut de page marque. Comme la méthode précédente, il suffit de
transmettre un identifiant utilisateur.
• Récupération des pages marques : Nous avons créer cette méthode pour que
l’administration puisse voir les derniers pages marques créer sur le site. Cela
permet une meilleure gestion de ces profils.
• Refus d’une demande pour devenir une page marque : Cette méthode permet à
un administrateur de refuser si la demande de l’utilisateur ne convient pas. Un
identifiant utilisateur est requis.
Les publications
• Création d’une publication : Pour pouvoir créer une publication, il suffit de

transmettre une description et des photos en paramètres. Il est également
possible de transmettre le titre d’un album, cela va engendrer la création
automatique d’un album. Si on veut que la publication soit placée dans un
album déjà existant, et autre que l’album “Upload”, il suffit de mettre un
identifiant album en paramètre.
• Suppression d’une publication : Pour supprimer une publication, il suffit de
donner en paramètre l’identifiant de la publication.
• Récupération des publications : On peut récupérer les dernières publications du
site. Pour pouvoir les récupérer par paquet, on peut rajouter les paramètres
“limit” et “offset”. Différentes méthodes de récupération sont disponibles.
Comme la récupération des publications en fonction d’un identifiant
utilisateur, ou celles des utilisateurs qu’on suit dans la communauté.
Les albums
• Création d’un album : Pour créer un nouvel album, il suffit de donner en

paramètre un titre, et au moins une photo.
• Suppression d’album : Pour supprimer un album, il faut juste transmettre
l’identifiant de l’album en paramètre.
• Rajout de photo(s) à l’album : Pour rajouter des photos, il suffit de donner en
paramètre l’identifiant de l’album concerné, ainsi que les photos.
• Suppression de photo(s) : Pour la suppression de photo(s), il faut juste donner
l’identifiant de l’album à la méthode, et transmettre un tableau comportant
les identifiants des photos qu’on veut supprimer.
• Récupération des albums : On récupère les albums en précisant l’identifiant de
l’utilisateur en paramètre.
Aimer
• Aimer un objet : Pour que l’utilisateur puisse aimer une photo, commentaire,
publication ou album. Il est nécessaire de fournir l’identifiant de l’objet que
l’utilisateur souhaite aimer et son type (photo, publication, album,
commentaire)
• Ne plus aimer : Cette méthode permet de ne plus aimer un objet
précédemment aimé par l’utilisateur que ce soit une photo, un album, une
publication ou un commentaire. Requiert l’identifiant de l’objet et son type.
• Vérifier qu’un objet est déjà aimer : Renvoie un booléen pour savoir si cet
objet est déjà aimé par l’utilisateur. L’identifiant de l’objet et son type.
Les commentaires
• Créer un commentaire : Pour créer un commentaire, il faut juste transmettre

le commentaire avec un identifiant d’objet, ainsi qu’un type d’objet. Il faut
préciser le type car on peut commenter un album, une publication, ou encore
une photo.
• Supprimer un commentaire : Il suffit de donner en paramètre l’identifiant du
commentaire.
• Edition d’un commentaire : Il faut communiquer l’identifiant du commentaire,
et le nouveau commentaire en paramètre.
• Récupération des commentaires : On communique l’identifiant, et le type de
l’objet pour récupérer le tableau des commentaires. Tout comme la
récupération des publications, pour pouvoir les récupérer par paquet, on peut
rajouter les paramètres “limit” et “offset”.
Suivi entre utilisateurs
• Suivre un utilisateur/une page marque : Pour suivre un utilisateur, il suffit de

transmettre en paramètre le pseudo de le la personne/page marque que l’on
veut suivre.
• Répondre à une requête de suivi : Dans le cas où un utilisateur a un compté
privée, il va recevoir une requête pour les demandes de suivi. Il recevra la
demande directement dans ces notifications, et grâce à l’API il pourra
répondre à cette requête en donnant en paramètre l’identifiant de l’objet
“FOLLOW”, ainsi que sa réponse booléenne.
• Annuler la demande de suivi : Pour annuler la demande, il suffit de donner en
paramètre le pseudo de l’utilisateur à qui on a envoyer le requête.
• Ne plus suivre : Pour ne plus suivre l’utilsateur, comme pour la méthode qui
permet de suivre, on donne juste le pseudo de l’utilisateur en paramètre.
• Récupérer les suiveurs : Pour récupérer le tableau des suiveurs, on a juste
besoin de communiquer l’identifiant de l’utilisateur concerné, et pour
récupérer les suiveurs par paquets, on peut rajouter les paramètres “limit” et
“offset”.
• Récupérer les utilisateurs que l’on suit : Tout comme la méthode pour
récupérer les suiveurs, on transmet l’identifiant de l’utilisateur, et on transmet
les paramètres “limit” et “offset” pour les récupérer par paquets.
Les notifications
• Récupération des notifications : On précise l’identifiant du réceptionneur des

notifications, et pour les récupérer par paquet, on peut préciser la “limit” et
l’”offset”.
• Changer le statu d’une notifications : Il est important d’informer le serveur
lorsque la notification a été vue. Nos notifications sont divisées en trois
catégories : Les commentaires / tags, les Suivis, et les “J’aime”. Pour informer
le serveur qu’on a vu les notifications d’une de ces catégories, il suffit de
préciser le paramètre “type”.
La recherche
• La recherche : Cette méthode permet de rechercher un utilisateur, une page

marque ou un “fashtag”. Pour pouvoir utiliser cette fonction, il faut
transmettre les mots clés que l’on souhaite rechercher et un filtre
correspondant aux types voulant être recherché par l’utilisateur.
Les “Fashthèmes”
• Création d’un “fashthème” : Cette méthode permet la création d’un

“fashthème” par un administrateur. Le fashthème étant le jeu hebdomadaire
du site autour d’un fashtag. Les paramètres requis sont le “fashtag” utilisé,
une description, la date du début, la date de la fin et la photo lié au
fashthème.
• Modification d’un “fashthème” : On peut modifier un fashthème grâce à cette
fonction. Il suffit d’envoyer le paramètre que l’on souhaite modifier
(description, fashtag, photo, date du début ou date de fin)
Compte premium
• Passage à un compte premium : Pour pouvoir passer un compte utilisateur en

mode premium qui permet à l’utilisateur de mettre en avant des publications
sur la page d’accueil du site.
• Ajout d’une publication à la liste de mise en avant : Permet à une publication
d’utilisateur d’intégrer la liste des postes qui seront mis en avant sur la page
d’accueil du site. L’identifiant de la publication de l’utilisateur est requis.
Les statistiques
• Statistiques des genres des utilisateurs : Permet de connaître les pourcentages

d’hommes et de femmes utilisateurs sur le site.
• Fashtags les plus populaires : Permet de récupérer une liste avec les fashtags
les plus populaires du site. Un paramètre optionnel pour limiter le nombre de
fashtags est disponible.
• Utilisateurs les plus suivis : Méthode pour connaître les utilisateurs les plus
populaires du site en fonction de nombres de personnes les suivant. Le nombre
d’utilisateurs en réponse peut être limité grâce à un paramètre optionnel.
• Publications les plus populaires : Pour pouvoir récupérer une liste contenant les
publications les plus aimées du site. Un paramètre optionnel pour limiter le
nombre de publications dans la liste est disponible.
• Publications les plus commentés : Permet d’obtenir une liste des publications
les plus commentées. Un paramètre optionnel pour limiter le nombre de
publications dans la liste est disponible.
Signaler des bugs
• Signaler un bug : Cette méthode permet de créer un signalement de bug par

l’utilisateur, pour pouvoir être par la suite réparer par les développeurs. Les
paramètres requis sont la plateforme concernée, la fonctionnalité concernée,
le message de l’utilisateur et les captures d’écrans.
• Répondre à un signalement : Permet à l’administrateur de répondre à un
signalement créé par un utilisateur. Les paramètres requis sont l’identifiant du
signalement, le message de l’administrateur et le status en cours (résolu, en
attente, suspendu ou invalide)
• Récupérer les signalements : L’administrateur a accès à cette méthode pour
récupérer tous les signalements créés par les utilisateurs ou seulement les
signalements de bugs.
B) Serveur
L’application web suit l’organisation par défaut d’un projet basique Symfony 2.
Cette configuration nous permet d’organiser notre serveur en plusieurs “bundles” liés
à une partie spécifique. Chaque bundle contient une ou plusieurs entités, des
controleurs, et toutes les ressources correspondantes telles que les vues, les fichiers
de styles, javascript etc.
Voici une liste de nos différents ‘bundles’:
• AdminBundle: Ce bundle nous permet d’avoir un contrôle administrateur de

notre site pour avoir un aperçu des différentes activités récentes (derniers
‘posts’ créés, derniers utilisateurs), une partie statistique (‘posts’ les plus
populaires, utilisateurs les plus populaires, etc), créer des fashthèmes.
• AlbumBundle: Ce bundle permet de faire toute la gestion des albums pour les
utilisateurs, mais également de la simple consultation. Il définit également
l’entité Album et Picture.
• ApiBundle: L’APIBundle hérite du bundle développé par la communauté
FriendsOfSymfony FOSRestBundle. Ca nous permet de gérer plus facilement sa
gestion. C’est dans ce bundle que nous mettons toutes les méthodes de l’API.
Nous avons crée un controller pour chaque fonctionnalité.
• CommentBundle: Ce bundle permet la gestion des commentaires pour
l’utilisateur et il définit aussi l’entité Comment lié aux commentaires.
• FashtagBundle: Ce bundle définit l’entité ‘Fashtag’ et contient les contrôle lié
aux Fashtags (création d’un fashtag, mais aussi les vues permettant de
regrouper tous les postes contenant un même fashtag.
• FashthemeBundle: Ce bundle définit l’entité ‘Fashtheme’ qui est utilisé par
l’administrateur par la suite, et les vues liées.
• HomeBundle: Ce bundle est utilisé pour contenir toutes les fonctionnalités que
l’on retrouve sur la page d’accueil. Le contrôleur de la page d’accueil est
contenu dans ce bundle ainsi que la vue auquel il est lié.
• LikeBundle: Il s’agit du bundle qui permet la gestion des ‘Like’ sur notre site.
Il contient aussi les fichiers Javascript utilisé pour avoir un ‘Like’ dynamique.
Ainsi que la définition de l’entité que l’on retrouve dans notre base de
données.
• NotificationBundle: La gestion des notifications est effectuée dans ce bundle
ainsi que la définition de l’entité des notifications.
• PosteBundle: Ce bundle contient l’entité définissant le ‘Poste’. Le contrôleur
s’occupant de la gestion des postes ainsi que les vues liés au poste.
• ProfileBundle: Ce bundle s’occupe exclusivement de la partie profil de
l’utilisateur et la gestion de ses paramètres. Il contient les différentes vues et
contrôleurs.
• ReportBundle: Ce bundle permet à l’utilisateur de signaler des bugs ou du
contenu interdit dans les ‘postes’ (photo, commentaire, description) et à
l’administrateur de répondre à l’utilisateur pour l’informer de la progression
sur le problème rencontré et son statut en cours. Toutes les entités, vues et
contrôleurs liés sont contenus dans ce bundle.
• StaticPageBundle: Ce bundle est utilisé pour regrouper toutes les pages
statiques qui ne comportent pas de fonctionnalités mais seulement des textes
informatifs.
• UpBundle: Ce bundle regroupe toutes les entités, contrôleurs et vues liées à
notre système de compte premium et les fonctionnalités liées à la mise en
avant.
• UserBundle: Ce bundle hérite à la base du bundle de FriendsOfSymfony,
FOSUserBundle, ce qui nous permet d’avoir une base pour l’entité d’un user
ainsi que quelques vues et contrôleurs de base pour les actions basiques
(connexion, inscription, page profil, etc). Nous sommes parties de cette base
pour ensuite surcharger ce bundle. Tout ce qui concerne le ‘user’ est
repertorié ici ainsi que l’entité et contrôle pour les ‘follow’.
Nous utilisons également des bundles déjà existant. Certains ‘bundles’ sont déjà
installés par défaut dans l’application web et sont stockés dans les ‘vendors’. Nous
sommes libres d’en rajouter, ou bien d’en retirer. Pour gérer ces “vendors”, il suffit
d’utiliser le ficher de configuration composer.json.
Voici quelques exemples de “vendors” que nous utilisons :
nelmio/api-‐doc-‐bundle : Gestion de la documentation de l’API.

friendsofsymfony/user-‐bundle : Gestion de toute la partie utilisateur
(connexion, création de compte, déconnexion etc.)
friendsofsymfony/rest-‐bundle : Gestion de l’API. Création des routes de type
REST. Le choix de la méthode (POST, GET, DELETE et autres), ce fait à travèrs les
annotations de ce “bundle”.
friendsofsymfony/facebook-‐bundle : Gestion de l’authentification par
Facebook.
ob/highcharts-‐bundle : Générateur de graphiques pour la partie statistique.
C) Mobile
a) Hiérarchisation
Le projet PhoneGap contient un ensemble de dossiers permettant de pouvoir le

compiler sous les différents systèmes d’exploitation mobiles. Nous retrouvons trois
principaux répertoires qui seront utiles lors du développement de notre application.
Screenshot des principaux dossiers du projet PhoneGap
• Le répertoire ‘Plugin’ qui permet d’ajouter de nouvelles fonctionnalités à notre

application, soit pour pouvoir ajouter un écran d’accueil ou une API qui
permettra de naviguer dans le système de fichier de l’appareil mobile.
• Le répertoire ‘platforms‘ dans lequel seront stockées les différentes version de
l’application pour chaque système d’exploitation. En effet à l’aide d’une
commande permettant l’ajout d’une nouvelle plate-forme, le code compilé de
cette nouvelle plate-forme sera ajouté dans un nouveau dossier.
• Le répertoire www qui contiendra un dossier pour chaque langage de
programmation que l’on utilise pour l’application (HTML, CSS et JS).
L'utilisateur voulant crée son application via Phonegap ira la crée à l’intérieur
de ce dossier en élaborant sa propre arborescence. (Voir photo ci-dessous pour
un exemple).
Voir screenshot de l’arborescence sur la page suivante
Screenshot de l’arborescence
b) Déploiement
Grâce à Ionic, nous pouvons appeler un binaire qui compilera le projet pour la
plateforme que l’on veut tester. Cela peut être pour iOS (Apple), Android ou Windows
Phone. Le binaire va nous transformer le code réalisé en HTML, CSS, Javascript dans
le langage voulu, c’est à dire Objective-c pour iOS, Java pour Android et C# pour
Windows Phone. Un exécutable sera alors créé pour chaque plateforme, il ne restera
plus qu’à tester l’application sur les différents émulateurs pour en vérifier son bon
comportement.
c) Test de l’application
Chaque plateforme à son émulateur attitré :
iOS pour tester l’application, il suffit d’ouvrir le fichier avec l'extension

“xcodeproj” avec le logiciel Xcode. A partir de Xcode nous pouvons choisir
sur quel type de téléphone nous pouvons tester l’application, donc cela peut être sur
l’iphone 4 ou 5 et autres. Nous avons aussi la possibilité de tester l’application sur
notre propre iPhone pour cela il suffit de le brancher au Mac et Xcode le reconnaitra
automatiquement.
Eclipse, qui est le logiciel pour l’environnement de developpement des

applications Android dispose aussi d’un émulateur inclu. Mais celui-ci jugé trop
lent, nous avons décidé d’utiliser Genymotion qui est aussi un émulateur pour
Android mais beaucoup plus rapide, de plus il est souvent mise à jour et nous pouvons
tester l’application sous les différents téléphones qui supportent Android (c’est à dire
de la gamme de téléphone de Samsung jusqu’au Nexus de Google). Il suffit de
transférer le fichier avec l'extension “apk” dans l’émulateur afin de pouvoir tester
l’application.
Windows Phone : Visual Studio propose aussi son propre emulateur, celui ci se
comporte un peu comme pour iOS, il suffit d’ouvrir le fichier avec l’extension
“sln” puis il suffit de cliquer sur le bouton “Play” afin de tester l’application
dans le controller.
d) Débuggage
Il est plutôt difficile de pouvoir effectuer du debug avec Phonegap, en effet les
émulateurs n’ont pas de console pour nous permettre de repérer les erreurs CSS ou
Javascript qui peuvent survenir. Pour cela nous plaçons des messages dans le code
pour qu’ils apparaissent lors de l’exécution de l’application afin de voir quel chemin
le code empreinte. Grâce à ces messages nous pouvons aussi afficher ce que
contiennent nos variables et donc bien vérifier le contenu de nos variables.
D) Base de données
a) User
Ce module représente toutes les informations liées à un utilisateur de

Moodress.
Ces informations servent à identifier l’utilisateur (pseudonyme, photo de

profil, ville…etc.) mais également à l’authentifier sur Moodress (la table utilisateur
contenant le login et le mot de passe).
Voir la classe de ce module sur la page suivante
Classe User
b) Post/Album/Commentaires
Ce module représente presque tout le contenu que contient le réseau social

Moodress.
Il se divise en 3 grandes parties :
• Les postes permettent de partager n’importe quel contenu qui est lié à la mode
(photo, demande d’avis, d’idée, etc.).
• Les albums qui sont utiles à l’organisation des anciennes photos postées.
Les commentaires qui apportent toute l’interaction entre les utilisateurs de Moodress.
Classes Post, Comment, et Album
c) Like
Le module like permet à tout utilisateur de donner son avis sur le contenu
partagé pas ces connaissances. Il permet également de voir une liste de tous les
contenus qu’il a aimé et ainsi de retrouver facilement un style qu’il a aimé par
exemple.
Classe Like
d) Notification
Le module de notifications permet simplement d’alerter l’utilisateur

(simplement visuellement sur le site / l’application, ou par email) de nouvelles
interactions sur son réseau (nouveau follower, nouveau commentaire, nouveau poste,
etc).
e) Tags / Fashtags
Le module de « fashtags » permet la catégorisation de ressources sur le site :

post, photos, albums. Le but est de créer des réseaux / communautés entre les
utilisateurs ayant les mêmes centres d’intérêts.
Classe Fashtag
f) Follower / Following
Le module de follower / following permet, à la manière de Twitter, de suivre

des utilisateurs du réseau (à l’aide des notifications entre autres) ou à l’inverse d’être
suivi par des personnes intéressées par votre profil et vos publications.
Classe Follower
g) Fashthème
Le module fashthème permet d’avoir en base de données les jeux que pourront
mettre en place les ‘community managers’ du site. Il contient les dates de début et
de fin du jeu, une description pour expliquer le thème aux utilisateurs, le fashtag qui
est utilisé pour participer.
h) Report
Ce module nous permet de représenter les signalements effectués par les

utilisateurs à propos de bugs rencontrés ou de contenu interdit dans notre base de
données. Il contient l’identifiant de l’utilisateur qui est le créateur, l’identifiant de
l’administrateur en charge du signalement, un message décrivant le problème, une
date de création, le statut en cours du signalement et enfin la réponse de
l’administrateur.
i) Up / Premium
Cette table permet de repertorier tous les postes qui sont mis en avant par les
utilisateurs premium. Elle contient l’identifiant du poste à mettre en avant ainsi que
la date de mise en avant.
5) Fixation de bug
Github possède un puissant outil pour nous permettre de tracker les bugs dans
notre projet. Nous avons décidé d’utiliser son système d’issues car les issues sont très
simples à créer. Il suffit d’un titre et de sa description. Il est alors très facile et
attractif de créer des issues pour les bugs qui doivent être fixés.
La première chose importante dans les issues sont les “labels”, étant donné
que nous utilisons aussi les issues comme une “Todo list”, nous avons besoin de lister
les bugs facilement, c’est donc là qu’interviennent les “labels”. En conclusion, nous
avons un label “bug” qui nous permet de trier les issues par bug.
Example de la liste de bugs sur Github avec les labels “bug”
Nous utilisons la structure suivante pour écrire nos issues :
• un titre simple et clair afin de pouvoir s’y retrouver facilement dans la liste des
bugs
• le contexte : on explique pourquoi nous ouvrons une nouvelles issue pour
résoudre un bug.
• le problème / idée : explication d’où pourrait provenir le problème et ainsi
donner une direction de comment il pourrait se résoudre.
• solution : c’est ici que les choses avancent, car nous pouvons assigner les issues
à des collaborateurs et ainsi ils peuvent discuter du problème puis proposer
leurs solutions dans les commentaires.
Une fois le bug résolu, la personne en charge peut faire son “commit” pour
“patcher” le code et attribuer ce commit au numéro de l’issue. Cela permet de
montrer aux autres collaborateurs comment la personne a pu résoudre ce problème
en montrant les lignes de codes qui ont été modifiées. Ainsi les collaborateurs
peuvent apporter des commentaires si il y en a besoin. Une fois cela terminé, l’issue
peut être ‘close’ sur Github et peut être aussi ‘re-open’ à l’avenir si le même bug
réapparaît.
Liste de bugs
• Lorsqu’on lance le serveur Moodress, le premier bug qui est souvent rencontré
est celui-ci :
RuntimeException: Failed to write cache file

"/var/www/myapp/app/cache/dev/classes.php".
Pour corriger ce bug il faut exécuter les lignes suivantes dans son shell :
$ chmod 777 app/cache

$ chmod 777 app/logs
$ rm -‐rf app/cache/*
$ rm -‐rf app/logs/*
Puis à la racine Symfony de son fichier:
$ php app/console cache:clear
• L’utilisation du langage est parfois à l’origine de certains bugs, comme par

exemple faire des comparaisons entre des variables, il est mieux d’utiliser
‘===’ que ‘==’ pour que l’opération soit faite que si les deux variables sont
strictement identiques.
• Erreur pour la création d’un utilisateur et l’insertion dans la base de donnée:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'nb_postes'

cannot be null "
Pour corriger ce type d’erreur SQL il faut mettre à jour le constructeur de la
classe concernée. Setter la valeur de la variable qui ne peut pas être null (voir ci-
dessous l’exemple):
/**
* Constructor
*/
public function __construct()
{
parent::__construct();
$this-‐>nbPostes = 0;
}

2015 TD3 FR Moodress

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2015 TD3 FR Moodress

Transféré par

Droits d'auteur :

Formats disponibles

tchiko_s bonet_g thiec_a ozkul_o pica_d

pons_c thomas_t labell_s

Ce document décrit l’intégralité de l’architecture du projet Moodress. Notre

Date Auteur Commentaire

24/02 – 16/03 Sandro Tchikovani Préparation du document, mise en page,

05/03 - 09/03 Steeven Labelle Les choix techniques

08/03 - 14/03 Arnaud Thomas Elaboration de plan pour la partie Réalisation.

08/03 - 14/03 Alan Thiec Elaboration de plan pour la partie Réalisation.

08/03 – 13/03 Omer Ozkul Partie architecture.

11/03 – 12/03 Guillaume Bonet Fixation de bugs

11/03 - 11/03 Thomas Tortorini Corrections

14/03 – 14/03 Dany Pica Corrections

03/07 - 03/07 Guillaume Rajout de la partie mobile

03/07 - 03/07 Arnaud Mise à jour par rapport à la version actuelle de

03/07 - 03/07 Alan Modification de la partie Module

04/07 – 04/07 Sandro Mise en page

02/10 - 05/10 Sandro,Dany,Omer Révision intégral du document, Mise en page

L' « École pour l'informatique et les nouvelles technologies » ou EPITECH, est

L’ « EPITECH Innovative Project » ou EIP, est la principale étape dans le cursus

A) « Use case » de notre architecture

Le cas d’utilisation de la barre de navigation est l’élément principal que

Voir le cas d’utilisation à la page suivante

Cas d’utilisation de la barre de navigation

Cas d’utilisation de la page d’accueil

Voir le cas d’utilisation de la vue détaillée d’une publication à la page suivante

Cas d’utilisation de la vue détaillée d’une publication

Cas d’utilisation de la page profil

La page des paramètres permet de modifier les éléments principaux de votre

Cas d’utilisation de la page paramètre

La page d'administrateur permet aux administrateurs d'analyser l'activité du réseau

Voir le cas d’utilisation de la page administrateur à la page suivante

Cas d’utilisation de la page administrateur

B) Diagramme global de notre solution

L’architecture d’un site et plus généralement d’un projet informatique correspond

Ces éléments définissent le « squelette » général de ce que sera notre projet. Il

• Temps de développement du projet

Voir le schéma de l’architecture globale à la page suivante

Schéma de l’architecture globale

C) Diagramme des entités

Voir le diagramme de classe de la base de données à la page suivante

Diagramme de classe de la base de données

Notre choix pour Symfony2 s'est fait grâce à plusieurs facteurs:

1. L'équipe de développement est composée d'une majorité de personnes ayant

développement d'une application hybride. Cordova offre tous les fonctionnalités

Nous utilisons les bienfaits de git et du service d'hébergement GitHub pour

• Création de compte : Les clients peuvent créer un nouveau compte. Il suffit de

Les pages marques

• Création d’une publication : Pour pouvoir créer une publication, il suffit de

• Création d’un album : Pour créer un nouvel album, il suffit de donner en

• Créer un commentaire : Pour créer un commentaire, il faut juste transmettre

Suivi entre utilisateurs

• Suivre un utilisateur/une page marque : Pour suivre un utilisateur, il suffit de

• Récupération des notifications : On précise l’identifiant du réceptionneur des

• La recherche : Cette méthode permet de rechercher un utilisateur, une page

• Création d’un “fashthème” : Cette méthode permet la création d’un

• Passage à un compte premium : Pour pouvoir passer un compte utilisateur en

• Statistiques des genres des utilisateurs : Permet de connaître les pourcentages

Signaler des bugs

• Signaler un bug : Cette méthode permet de créer un signalement de bug par

Voici une liste de nos différents ‘bundles’:

• AdminBundle: Ce bundle nous permet d’avoir un contrôle administrateur de

Voici quelques exemples de “vendors” que nous utilisons :

nelmio/api-­‐doc-­‐bundle : Gestion de la documentation de l’API.

Le projet PhoneGap contient un ensemble de dossiers permettant de pouvoir le

nelmio/api-‐doc-‐bundle : Gestion de la documentation de l’API.