Академический Документы
Профессиональный Документы
Культура Документы
Documentation technique
L’équipe Moodress :
Documentation technique
Résumé :
2015_TD3_FR_Moodress.pdf
Documentation technique
Tableau de révision :
2015_TD3_FR_Moodress.pdf
Documentation technique
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
2015_TD3_FR_Moodress.pdf
Documentation technique
1) Contexte
2) 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.
2015_TD3_FR_Moodress.pdf 1
Documentation technique
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.
2015_TD3_FR_Moodress.pdf 2
Documentation technique
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.
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.
2015_TD3_FR_Moodress.pdf 3
Documentation technique
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.
2015_TD3_FR_Moodress.pdf 4
Documentation technique
2015_TD3_FR_Moodress.pdf 5
Documentation technique
2015_TD3_FR_Moodress.pdf 6
Documentation technique
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.
2015_TD3_FR_Moodress.pdf 7
Documentation technique
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.
2015_TD3_FR_Moodress.pdf 8
Documentation technique
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.
2015_TD3_FR_Moodress.pdf 9
Documentation technique
3) Choix techniques
Symfony 2
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
2015_TD3_FR_Moodress.pdf 10
Documentation technique
Github
2015_TD3_FR_Moodress.pdf 11
Documentation technique
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.
• 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.
2015_TD3_FR_Moodress.pdf 12
Documentation technique
• 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
Les albums
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.
2015_TD3_FR_Moodress.pdf 13
Documentation technique
• 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
Les notifications
2015_TD3_FR_Moodress.pdf 14
Documentation technique
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
Les “Fashthèmes”
Compte premium
Les statistiques
2015_TD3_FR_Moodress.pdf 15
Documentation technique
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.
2015_TD3_FR_Moodress.pdf 16
Documentation technique
• 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.
2015_TD3_FR_Moodress.pdf 17
Documentation technique
C) Mobile
a) Hiérarchisation
2015_TD3_FR_Moodress.pdf 18
Documentation technique
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.
2015_TD3_FR_Moodress.pdf 19
Documentation technique
c) Test de 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
2015_TD3_FR_Moodress.pdf 20
Documentation technique
Classe User
b) Post/Album/Commentaires
• 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.
2015_TD3_FR_Moodress.pdf 21
Documentation technique
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
e) Tags / Fashtags
Classe Fashtag
f) Follower / Following
Classe Follower
2015_TD3_FR_Moodress.pdf 22
Documentation technique
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
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.
2015_TD3_FR_Moodress.pdf 23
Documentation technique
• 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 :
Pour corriger ce bug il faut exécuter les lignes suivantes dans son shell :
2015_TD3_FR_Moodress.pdf 24
Documentation technique
/**
*
Constructor
*/
public
function
__construct()
{
parent::__construct();
$this-‐>nbPostes
=
0;
}
2015_TD3_FR_Moodress.pdf 25