View
2
Download
0
Category
Preview:
Citation preview
2017
Rapport
IFT3150 – PROJET INFORMATIQUE
LOUIS-EDOUARD LAFONTANT
1 | P a g e
Table des matières
Introduction ......................................................................................................................................................................... 3
Objectif ............................................................................................................................................................................ 3
Proposition ...................................................................................................................................................................... 3
Analyse .................................................................................................................................................................................. 4
Besoins fonctionnels ...................................................................................................................................................... 4
Besoins non fonctionnels .............................................................................................................................................. 4
Méthodologie et approche adoptée ............................................................................................................................. 4
Comportement du système ........................................................................................................................................... 5
Justification des choix .................................................................................................................................................... 6
Conception ........................................................................................................................................................................... 8
Modèles utilisés ............................................................................................................................................................... 9
Justification des choix .................................................................................................................................................. 10
Patrons de conception ................................................................................................................................................. 11
Conception des paquets .............................................................................................................................................. 12
Implémentation ................................................................................................................................................................. 13
Base de données ........................................................................................................................................................... 13
Web API ........................................................................................................................................................................ 14
Application mobile ....................................................................................................................................................... 16
Tests et documentation .................................................................................................................................................... 18
Tests fonctionnels ........................................................................................................................................................ 18
Tests structurels ............................................................................................................................................................ 19
Documentation ............................................................................................................................................................. 20
Conclusion ......................................................................................................................................................................... 21
Remerciements .................................................................................................................................................................. 21
Bibliographie ...................................................................................................................................................................... 22
Annexes .............................................................................................................................................................................. 24
2 | P a g e
Annexe 1 : Cas d’utilisations ....................................................................................................................................... 24
Annexe 2 : Modèle entités-associations .................................................................................................................... 25
Annexe 3 : Diagrammes d’activités UML................................................................................................................. 26
Annexe 4 : Diagramme de paquets ............................................................................................................................ 30
Annexe 5 : Application mobile ................................................................................................................................... 31
Table des figures
Figure 1 - Message d’erreur 404 ........................................................................................................................................ 8
Figure 2 - Spécifications du UI ......................................................................................................................................... 9
Figure 3 – Classe Startup ................................................................................................................................................. 15
Figure 4 – Classe UserFolderController ........................................................................................................................ 16
Figure 5 – Test unitaire GetUniversity_ReturnsHttpNotFound .............................................................................. 20
3 | P a g e
Introduction
Le monde des étudiants est un univers dynamique et quoiqu’elle se situe dans une courte période (en moyenne
5 ans), elle est unique et riche en expérience dans la vie d’un individu. Il se distingue nettement de
l’environnement dirigé et les possibilités d’actions limitées de l’école. Cet univers contraste également avec
l’univers du travailleur beaucoup plus statique et concentré dans une tache spécifique, pratiquée régulièrement.
Les étudiants doivent constamment jongler avec de multiples demandes changeantes et dispersées.
Il faut avoir une vie sociale, participer aux évènements, s’impliquer dans les programmes de son association,
interagir avec d’autres étudiants. La façon d’étudier aussi change dramatiquement avec une liberté qui laisse
beaucoup d’étudiants égarés, incapables de suivre car l’étude ne se termine pas en classe, elle continue à la
maison, à la bibliothèque, sur le web et partout où l’on peut trouver une information nous aidant à mieux
comprendre et maitriser la matière. Finalement, il faut rester informer, aussi bien des annonces universitaires
que des nouvelles du monde ou de celles liées à leur domaine d’étude.
Objectif
Pour permettre un meilleur équilibre et une transition plus souple, nous tenterons de créer toute l’infrastructure,
c’est-à-dire, de la base de données à l’interface utilisateur, pour supporter Scoti : une plateforme de
communication et collaboration pour étudiant.
Proposition
Pour réaliser une telle plateforme nous avons identifié trois aspects importants de la vie étudiante : le
social, la connaissance et l’information. Ils formeront les piliers de la solution et seront présents à travers
toutes les fonctionnalités développées.
Social
Le Social réunit toute forme d’interaction ou d’activité récréative telle que des évènements sociaux, mais aussi
dans un degré plus faible, les actions de partage et de réseautage sur la plateforme.
Connaissance
La Connaissance rassemble toute initiative prise sur la plateforme afin d’aider un étudiant à mieux comprendre
un concept en posant ou répondant à une question théorique par exemple.
Information
L’information regroupe les échanges provenant de l’intérieur ou de l’extérieur de la plateforme visant à informer
l’étudiant d’une situation spécifique : un étudiant cherchant un livre ou général comme le statut de la rampe.
La plateforme offre aussi, en complément aux 3 axes, des outils d'organisation permettant à l'étudiant d’être
plus productif et efficace durant son parcours académique.
4 | P a g e
Analyse
Ce projet fait suite à une première tentative, le projet Toodle (Hiver 2016), d’améliorer le service offert aux
étudiants chez qui le besoin d’un tel outil avait été validé. L’application mobile Toodle consistait principalement
à améliorer le système actuel de StudiUM en y ajoutant des fonctionnalités jugées essentielles et approuvées
par les étudiants : gestion de cours, calendrier, messagerie.
Depuis, les besoins ont été revus et raffinés pour mieux aider l’étudiant avec une approche différente du système
actuel consistant en un centre étudiant administratif et une application pour trouver le matériel d’études via les
solutions populaires Moodle ou Blackboard.
Besoins fonctionnels
L’application doit implémenter les fonctionnalités suivantes :
• Capable de fonctionner hors-ligne
• Fonctionnalités décrites dans les cas d’utilisations (voir l’annexe 1)
Besoins non fonctionnels
Scoti doit aussi suivre les contraintes suivantes :
• Utilisable par tout étudiant universitaire : Ceci relève du langage et jargon utilisés dans l’application
ainsi que la façon d’interagir avec les appareils mobiles.
• Ouvert à l’ajout d’une application web : L’implémentation de la solution doit permettre d’y ajouter
facilement une application web et d’autres clients voulant se servir de la plateforme.
• Utiliser Xamarin et ASP.NET Core pour le développement : Ce besoin découle de l’équipe de
programmation, expérimenté dans le développement .NET.
• Assurer la synchronisation des données : Les données doivent être synchronisés dès que possible
avec le serveur.
• Maintenable : Une application suivant les méthodes de développement logiciel ainsi que les bonnes
pratiques de conception (SOLID, DRY, KISS).
Méthodologie et approche adoptée
Avant même de se lancer dans la conception du programme, il nous faut une méthode de travail. Pour ce projet
nous suivons un processus de développement itératif et incrémental permettant de tester l’application tout
au long du développement, déterminer et résoudre les risques plus tôt. Ce processus offre une bonne flexibilité
qui est nécessaire pour ce genre de projet où il faut pouvoir rapidement s’adapté aux besoins changeants et aux
feedbacks des clients et utilisateurs. Nous faisons aussi usage du puissant outil de modélisation, UML 2.0
(standard dans le monde du développement de logiciel) pour décrire nos scénarios avec des cas d’utilisation, les
5 | P a g e
principaux flux d’activités de l’application avec des diagrammes d’activités et la conception des paquets de l’API
par un diagramme de paquets.
Comportement du système
Pour avoir une idée du fonctionnement et de l’utilisation de l’application mobile, des diagrammes d’activités
UML présentés en annexe 3 ont été utilisés. Les situations présentées ici sont les scénarios clés de l’application.
Ouvrir l’application
La première activité présente la démarche suivie pour ouvrir l’application. Il faut une solution simple et rapide
de sorte que l’utilisateur puisse rapidement commencer à utiliser l’application et apprécier son utilité. Il faut
aussi un moyen de garantir que l’utilisateur est un étudiant. Cette activité décrit deux scénarios : inscription d’un
utilisateur et connexion d’un utilisateur.
L’inscription se fait en une étape où l’étudiant fournit une adresse courriel académique et crée son mot de passe.
Un lien de confirmation lui sera envoyé mais il pourra déjà commencer à utiliser l’application en choisissant ces
cours et intérêts. Il rencontre ainsi très vite ce qui l’intéresse.
La connexion pour un étudiant déjà inscrit ne demande que son courriel et mot de passe qui, lorsque valide, le
transporte vers son journal lui montrant des notifications captant son attention.
Mon Journal
Ce second diagramme présente à l’étudiant un flot de notifications pertinentes facilement repérable et la capacité
d’aller dans les autres sections importantes de Scoti : Question et Fichier. Pour cela, ils sont tous accessibles en
une étape ce qui facilite grandement la navigation.
Question/Réponse
La troisième activité nous dirige vers un comportement classique chez les étudiants : poser des questions et y
répondre. Elle est donc l’une des plus riches en fonctionnalités. À l’entrée de l’activité, les questions liées à la
section active sont récupérées. L’espace est divisé entre les questions favorites, celles posés par l’étudiant et
celles des autres étudiants (public).
Chaque section présente une liste de questions avec, pour chacune, des informations pertinentes. L’étudiant
peut en tout temps poser une question s’il n’a pas déjà cinq questions ouvertes, c’est-à-dire, des questions qu’il
a posées sans accepter une réponse. Dans le cas où il peut poser une question, il faut en plus du titre, au
minimum un tag identifiant le propos de la question. Il peut aussi y ajouter un corps développant la question et
poser la question anonymement.
En cliquant sur une question, l’étudiant obtient le détail et les réponses. Les actions possibles sont les suivantes :
• Donner une appréciation (vote) à la question ou à la réponse ou signaler celle-ci si elle est offensante
ou ne respecte pas les règles de conduite. Le choix d’une appréciation au lieu d’un vote (binaire) est
6 | P a g e
important car cela traduit mieux le comportement des étudiants vis-à-vis d’une question ou une
réponse. Dépendamment de la relation de l’étudiant avec la question, la réponse peut être appréciée
selon son utilité, sa complétude et justesse.
• Donner sa réponse à la question ou à une réponse. Cette approche évite les commentaires et permet
de compléter une réponse ou de la corriger.
Si la question est celle de l’étudiant et ne contient pas de réponse, il peut décider de la fermer (supprimer du
domaine public) ou la booster et ajouter une récompense pour celui dont la réponse est acceptée.
Organiser son travail
Ce dernier diagramme présente l’organisation des fichiers et dossiers de l’étudiant. À l’entrée de l’activité le
système récupère les dossiers et fichiers du compte (Scoti par défaut). L’étudiant peut naviguer entre différents
comptes de stockage : Scoti et Dropbox (après avoir lié son compte à l’application).
Qu’importe la solution de stockage, il peut renommer un dossier ou le supprimer. Le partage de dossiers et
fichiers dépend des permissions accordées à l’étudiant. Dans un dossier il peut uploader un fichier, chatter avec
ceux qui partagent ce dossier et commenter les fichiers.
Justification des choix
Xamarin
Pour développer une application mobile, il existe actuellement 3 stratégies : natif, hybride, web.
L’analyse portera uniquement sur le développement natif et hybride car l’approche basé sur le web est sans lien
direct avec le modèle natif.
Le développement natif classique consiste à créer une application pour une plateforme spécifique
installé directement sur l’appareil en utilisant le langage du système ; Objectif-C ou Swift pour iOS et
Java ou Kotlin pour Android. Elle offre potentiellement la meilleur performance, l’interface (UI) la plus
raffinée et l’expérience utilisateur (UX) la plus agréable.
C’est donc la meilleure solution pour l’utilisateur mais pas nécessairement pour les développeurs qui doivent
connaitre et maitriser chaque système d’exploitation (OS), leurs langages et les standards existants. Ceci ajoute
un coût de développement et maintenance énorme car il faut aussi que les applications soient synchronisées en
termes de fonctionnalités et que l’expérience soit la même.
La solution hybride consiste à utiliser les outils du web (HTML, Javascript, CSS) pour créer
l’application. Celle-ci est imbriqué dans un WebView lors du déploiement et l’utilisation. Cette solution est la
plus rapide et la moins couteuse en termes de développement et maintenance car il n’existe qu’un code source
pour toutes les plateformes. Cependant elle vient avec son lot de compromis malgré les progrès de l’industrie :
• Mauvaises performances car elle est toujours dans un WebView.
7 | P a g e
• UI/UX pauvre car elle ne suit pas les standards des plateformes.
• Toutes les fonctionnalités ne sont pas disponibles automatiquement car il faut qu’un plugin ait été créé
par le Framework utilisé : PhoneGap/Cordova d’Apache, Ionic de Drifty, NativeScript de Telerik.
Xamarin est une solution native permettant de faire le développement d’application mobile multiplateforme
s’attaquant aux contraintes du développement classique cité plus haut. Ceci est rendu possible par l’utilisation
d’un seul langage, C# pour la programmation logique permettant le partage de près de 70% du code entre
toutes les plateformes. Utilisé par plusieurs grandes entreprises (Slack, GitHub, Foursquare, Pinterest), ses
avantages sont nombreux :
• UI natif fidèle à la plateforme.
• Performance très proche du natif sur Android et quasi égale sur iOS.
• Xamarin TestCloud : permet d’exécuter une série de tests automatisés sur plus de 2000 appareils.
• HockeyApp : support DevOps, permettant de distribuer une version beta de l’application et collecter
du feedback de vrai utilisateur en temps réel.
Les autres avantages du développement avec Xamarin proviennent de l’utilisation de Mono qui est une version
(compatible) du .NET Framework offrant toutes les fonctionnalités de ce dernier décrit plus bas.
ASP.NET Core
Ce nouveau Framework optimisé pour le cloud tire son origine de ASP.NET qui est la solution web du .NET
Framework. Apparu récemment (version 1.0 en juin 2016), il offre un tas de nouveaux avantages en
comparaison avec son ancêtre. ASP.NET Core peut être utilisé avec .NET Core déployable sur tous les
systèmes (Windows, OSX, Linux). Il est modulaire donc lors du déploiement, seules les composantes utilisées
sont incluses dans le paquet, le rendant beaucoup plus léger.
Comme décrit plus haut, les avantages du .NET Framework sont toujours présents :
• Language Integrated Query (LINQ) : Offre une syntaxe commune pour écrire des requêtes
directement dans le code sur toute collection de données (listes, base de données…). Les erreurs sont
attrapées à la compilation et LINQ est fortement typé.
• async/await : Facilite le développement de programme multithread et les appels asynchrones.
• C# (en comparaison avec Java) : Le langage offre un support intégré de generic, lambda, variable
dynamique (dynamic), types anonymes, getters et setters simplifié et autres.
• Entity Framework Core (EF Core) : Évolution du mapping objet-relationnel (ORM) Entity
Framework permettant de créer la base de données et la contrôler à partir du code utilisé pour le back-
end (style Code First). Il intègre les principes de Repository Pattern et Unit of Work pour manipuler
les entités directement dans le code et permet de faire des mises à jour en lots.
8 | P a g e
Conception
Toute l’infrastructure repose sur une bonne conception et modélisation des principales composantes :
• Le modèle relationnel schématisé par le diagramme entité-association présenté dans l’annexe 2. Il
doit être robuste, normalisé lorsque possible et flexible afin de s’adapter aux besoins du client et des
utilisateurs. La normalisation n’est pas stricte pour permettre des gains de performance.
• Les spécifications de l’API permettant de communiquer et manipuler les données dans la base de
données ou sur le disque. Afin de la rendre facile d’utilisation, nous appliquons une série de bonnes
pratiques énoncées ci-dessous.
o Suivre au mieux les principes de l'architecture REST (REpresentational State Transfer).
o Utiliser des noms et non des verbes pour décrire les ressources.
Exemple : /courses au lieu de /getAllCourses.
o Utiliser des noms au pluriels pour identifier les ressources.
o Format des réponses : JSON, préférence dans l’industrie. Beaucoup moins verbeux que le
XML et donc plus léger mais aussi plus lisible pour les humains.
o Format des dates : ISO 8601, standard international spécifiant la représentation numérique de
la date et de l’heure.
o Supporter la pagination, le filtrage et le triage des réponses.
o Utiliser des objets de transfert de données (DTO) pour les échanges de données. Ceci limite
les données acceptées par les endpoints permettant un meilleur contrôle des données à modifier.
o Toujours valider les données reçues.
o Utiliser JSON Web Token (JWT) avec l'algorithme HMAC-SHA256 pour l’authentification.
o Supporter le style HATEOAS (Hypermedia As Engine of Application State) permettant de
récupérer les ressources connexes plus efficacement.
o Utiliser les codes d'erreurs HTTP classiques (200, 201, 204, 304, 400, 401, 403, 404, 422, 500)
et un message d'erreur donnant une explication claire. Exemple :
Figure 1 - Message d’erreur 404
{ Code: 404 Summary: “Course not found” Errors: [ { Field: “id”. Message: “There is no course in the database with the ID: 0” } ] }
9 | P a g e
• Les spécifications de l’interface de l’application mobile avec laquelle l’utilisateur interagit. Celle-ci
doit être pratique et simple à utiliser pour tout étudiant. La figure ci-dessous illustre les spécifications
en utilisant les symboles suivants : FENETRE ; widget ; option1|option2 ; <bouton> ;
[cliquable] ; actif ; {liste} ; min0*, min1+, optionnel? ; (groupe) ; retour<-
Figure 2 - Spécifications du UI
Modèles utilisés
Pour construire l’API conformément à ce qui est utilisé dans l’industrie, nous utilisons également des modèles
comme source d’inspiration. Ayant fait leurs preuves, ils permettent d’éviter certaines erreurs de conception.
Ces modèles sont les suivants :
• Dropbox API pour la structure de l’API et les rôles et permissions dans la section des fichiers ;
• Google Drive API pour la structure de l’API et les erreurs ;
• OneDrive API pour la structure de l’API et la section des fichiers ;
• Slack pour les rôles et permissions dans la section des fichiers ;
Les modèles ne se limitent pas uniquement à l’API mais s’étendent aussi à l’application mobile :
SIGNUP LOGIN
fullName username|university_email
university_email password
password <login>
<sign_up>
JOURNAL
{notification}
[Journal|Questions|Files]
QUESTIONS <- QUESTION
[Favorites|Yours|Public] question<favorite><flag>
{[question]?} {(answer<vote><answer><flag>)?}
<ask> <answer>
[Journal|Questions|Files]
ASK ANSWER
title body
body? <send>
tag+
anonymous
<send>
FILES <- FOLDER <- FILE
[Scoti|Dropbox] {[folder|file]?} file_info
{[folder|file]?} <chat> <comment>
[Journal|Questions|Files] <share> <share>
<upload_file>
10 | P a g e
• StackOverflow pour la structure des questions/réponses, les règles de validation, les récompenses et
l’interface de la section Questions ;
• Quora pour la présentation des questions et l’interface en général ;
• Yahoo Answers pour les règles de validation et les récompenses ;
• Reedit pour les règles de validation et les interactions ;
• Drive pour l’interface de la section Files et l’interface en général ;
• Toodle pour l’interface de la section Journal
Justification des choix
Prenant un moment pour comprendre certains des choix faits dans la conception de l’API.
Architecture REST
Un RESTful API imite la façon dont le web lui-même fonctionne dans les échanges client-serveur. Il se
contraint aux règles suivantes :
• Client-serveur indépendant : Séparation des responsabilités entre le client et le serveur.
• Sans état : Le serveur n’a aucune idée de l’état du client entre deux requêtes.
• Avec cache : Un client doit être capable de garder en mémoire les informations sans avoir besoin de
tout demander au serveur.
• Avec une interface uniforme : Identification des ressources, manipulation des ressources par des
représentations, messages autodescriptifs, hypermédia (HATEOAS).
• Avec un système de couche : Chaque composant voit uniquement les composants de la couche avec
laquelle il interagit directement.
En suivant ces règles, nous obtenons les avantages suivants :
• La maintenance est plus facile grâce à la séparation client-serveur.
• Le serveur peut répondre à d’autres requêtes plus rapidement car il n’y a pas de gestion d’état et donc
pas besoin de connexion permanente maintenue avec le client. Les requêtes peuvent également être
réparties sur plusieurs serveurs.
• L’utilisation du protocole http permet de tirer parti de son enveloppe et ses en-têtes.
• L’utilisation d’URI comme représentation d’une ressource permet d’avoir un système universel
d’identification des éléments de l’application.
Style HATEOAS
Ceci est le plus récent ajout aux contraintes d’un RESTful API. Il permet de lier la ressource cible (appelé
par une méthode HTTP) à d’autres ressources via des liens et ainsi connaitre les actions possibles sur les
11 | P a g e
ressources ainsi que les relations entre ressources. Grâce à cela, le client saura s’adapter aux changements de
l’API et naviguer l’API plus facilement.
Authentification avec JWT
JSON Web Token est un standard ouvert (RFC 7519) pour échanger de l’information de manière
sécurisée via un jeton composé de 3 parties : un entête, une charge utile et une signature. La signature utilisée
dans ce cas est créée à partir de l’algorithme sécuritaire HMAC-SHA256.
La force de JWT est qu’il s’occupe de la session de l’utilisateur sans maintenir d’état. L’utilisation de claims
permet d’extraire les informations telles que l’ID et le nom d’utilisateur de l’utilisateur sans avoir à envoyer une
requête à la base de données. Ceci nécessite cependant une date d’expiration associé au token pour éviter qu’il
soit réutilisé par quelqu’un d’autre.
Patrons de conception
Afin de développer une solution robuste et maintenable, nous faisons la conception par patrons. L’application
mobile fonctionne selon le paradigme de programmation évènementielle mais n'est pas incompatible avec la
programmation orienté-objet. Le flot est guidé par des notifications d'évènements au lieu d'appel de méthode.
Patrons de construction
Utile pour abstraire le processus d’instanciation et rendre le système indépendant de la façon dont les objets
sont créés, composés et représentés. Ci-dessous les patrons utilisés dans cette catégorie :
• Constructeur : Il permet de construire des objets complexes avec différentes représentations comme
les Dialog dans l’application mobile.
• Singleton : Il est utilisé pour les objets qui doivent être créés une seule fois, c’est-à-dire, une instance
pour l’application comme ViewModelLocator.
Patrons de structure
Utile pour définir la façon dont les classes et objets sont composés pour former de plus grandes structures. Ci-
dessous les patrons utilisés dans cette catégorie :
• Adapteur : Il donne accès à son implémentation interne sans pour autant coupler les clients à son
implémentation interne. Ce patron est utilisé pour intégrer le Dropbox SDK dans l’application mobile
et fournir une interface commune pour la manipulation des fichiers.
• Observateur : Il permet à plusieurs composantes de communiquer sans constamment vérifier le statut
de l’objet. Il est notifié lors du changement permettant ainsi un couplage minimal. Ce patron est surtout
utile dans l’application mobile faisant usage du modèle MVVM décrit plus bas.
• Façade : Il permet d’abstraire la complexité du système en fournissant une interface commune. On
est fait usage dans le Repository Pattern décrit plus bas.
12 | P a g e
Patrons d’architecture
• Model-View-ViewModel (MMVM) : Implémentation du patron Model-View-Controller (MVC), il
fait lui aussi usage des patrons de l’Observateur et du Mediateur.
MVVM permet de séparer la vue, la logique et l’accès aux données en accentuant les principes de data-
binding (aussi une forme de MVC) qui permet de lier des objets entre eux pour les faire communiquer,
et d’événement. Ceci rend le code lié à l’interface plus facile à tester.
o View : Il informe le ViewModel des actions de l’utilisateur.
o ViewModel : Il expose les données du Model et commandes possibles à la vue associée.
o Model : Il représente les données de l’application et communique continuellement avec le
ViewModel pour récupérer et sauvegarder les données.
Ce patron est au centre de l’application mobile.
• Architecture 3-tier : Cette architecture facilite la maintenance et le développement de la plateforme.
L’application mobile représente le tier de présentation, l’API représente le tier de la logique et la base
de données et le disque de stockage occupent le tier des données.
Repository pattern
Ce patron est utilisé dans l’API et l’application mobile pour séparer la logique du domaine (business logic) de la
logique faisant l’accès aux données, ainsi cette dernière peut être testée séparément. Nous pouvons aussi plus
facilement modifier la façon d’accéder aux données sans briser le reste du code.
Conception des paquets
La solution se divise en 3 paquets, ScotiAPI, ScotiApp.Core, ScotiApp.Droid pour le code de l’API, le
code partagé par les applications mobiles et le code de l’application mobile Android respectivement.
ScotiAPI
Ce paquet détaillé à l’annexe 4, fait référence au paquet Common qui contient des fonctions pratiques
(principalement des extensions) réutilisables à travers plusieurs projets. Comme nous pouvons le constater,
ScotiAPI est composé de 8 paquets :
• Data : Ce paquet contient les classes responsables de créer et initialiser la base de données. Il dépend
du paquet Models. Ceci le rend donc irresponsable (I = 1). Cependant il n’a aucune abstraction (A = 0),
faisant de lui un excellent paquet (D = 0).
• Endpoints : Ce paquet contient les points d’entrées de l’API et est donc très irresponsable (I = 1) et
aussi peu abstrait (A = 0.14) ce qui donne lieu à un bon paquet (D = 0.14).
13 | P a g e
• Services : Ce paquet contient les classes servant à communiquer avec la base de données et le disque.
Il dépend du paquet DTO (I = 0.75) et est assez abstrait (A = 0.50) résultant sur un paquet plutôt
bien balancé (D = 0.25).
• DTO : Ce paquet contient les DTO utilisé pour composer les réponses de l’API ainsi que ses
paramètres. Il est assez indépendant (I = 0.33) et peu abstrait (A = 0.19) résultant sur un paquet
suffisamment équilibré (D = 0.48).
• Helpers : Ce paquet contient les classes permettant de faciliter certaines opérations utilisées à travers
le code comme LinkBuilder (crée des liens). Il est très responsable et indépendant (I = 0) et assez
abstrait (A = 0.50), ainsi assez bien balancé (D = 0.50).
• Models : Ce paquet contient les classes qui formeront la base de données avec une classe abstraite
BaseModel définissant les propriétés communes tels que : Id, CreationDate, LastModifiedDate. Ce paquet
est très stable (I = 0) car il n’a aucune dépendance mais pas très abstrait (A = 0.02). Il est tout de
même un bon paquet malgré son score (D = 0.98) dû à la nature des classes le composant.
• Options : Ce paquet contient les classes de configurations et n’a donc aucune dépendance (I = 0) mais
aussi aucune abstraction (A = 0) ce qui dans ce cas est acceptable malgré son pauvre score (D = 1).
De manière générale, nous pouvons dire que les paquets sont équilibrés (D moyen = 0.48)
ScotiApp
Ce paquet est divisé en 2 paquets ScotiApp.Core et ScotiApp.Droid. Cette séparation a été faite afin de faciliter
l’ajout d’implémentation pour d’autres plateformes comme iOS ou UWP (Windows). Ainsi ScotiApp.Core
contient toute la logique commune aux multiples plateformes et chacune des implémentations a son propre
paquet, comme ScotiApp.Droid, avec la définition de leur interface.
Implémentation
Pour le développement, nous utilisons Visual Studio 2017 – Community comme environnement de
développement (IDE), un des plus réputés au monde. Il nous permet entre autres de manipuler la base de
données en intégrant SQL Server Express, d’organiser notre solution en projets (paquets), de visualiser
l’interface avec Xamarin et de faire les tests par xUnit.
Base de données
Une analyse des besoins nous a permis d’identifier les principales entités composant notre modèle relationnel
qui servira de base pour la construction de notre base de données. En considérant notre expérience et les outils
choisis pour le développement (EF Core), SQL Server sera utilisé pour la gestion de la base de données.
14 | P a g e
Ce système de gestion de base de données (SGBD) crée par Microsoft est l’un des meilleurs sur le marché. Son
intégration avec Azure en fait aussi un excellent candidat lors du déploiement.
Dans notre implémentation avec EF Core – Code First, en C#, nous utilisons principalement la structure int pour
les clés primaires, byte (équivalent de tinyint pour SQL Server) pour les tables de supports et Guid pour les tables
liées aux fichiers et dossiers. Celles-ci sont générées automatiquement par le SGBD à la création de
l’enregistrement.
Grâce au Code First nous pouvons utiliser directement des enums pour certaines tables ou colonnes dont les
données resteront fixes telles que les statuts (InvitationStatus, QStatus), les types (FlagType, AppreciationType,
QType), les valeurs (Vote, FolderRole). Ceci facilite beaucoup l’utilisation de ces données dans le code.
Nous faisons aussi usage des classes abstraites pour avoir une entité de base, BaseEntity avec les colonnes
partagées par la majorité des tables : ID, CreationDate, LastModifiedDate ; de la composition pour les colonnes
répétées à travers plusieurs tables comme l’adresse (Address).
Les entités sont regroupées selon 4 domaines dans le code comme décrit ci-dessous.
• Académique (Academic) : Ce domaine regroupe toutes les entités servant à représenter les universités,
programmes, cours et leurs tables de supports respectives.
• Question/Réponse (QA) : Ce domaine regroupe toutes les entités servant à représenter les questions,
réponses, sujets et leurs tables de supports respectives.
• Fichier (Storage) : Ce domaine regroupe toutes les entités servants à représenter les dossiers, fichiers
et leurs tables de supports respectives.
• Personne (Person) : Ce domaine regroupe toutes les entités servant à représenter les individus
spécialistes tel que les professeurs, utilisateurs et leurs tables de supports respectives.
Web API
Le service web est implémenté avec ASP.NET Core. Le Framework utilise une série de middleware qui traite
chaque requête en chaine. La classe Startup (montrée à la figure 3) permet de mettre sur pied toutes les pièces
nécessaires incluant le routage (routing).
ASP.NET Core fonctionne par convention (modifiable). À la réception d’une requête, l’URL est décomposée
pour être comparée avec le nom attribué aux contrôleurs (classes regroupant plusieurs endpoints) puis celui
attribué aux méthodes avec l’attribut correspondant.
Exemple de requête GET : https://scoti.com/api/courses
Contrôleurs : Users, Files Courses
Le nom du contrôleur correspond à la ressource de la requête.
Méthodes de Courses :
15 | P a g e
[GET]GetAllCourses(), [GET(“{id}”)]GetCourse(int id), [POST]GetCourses
La méthode correspond au type de requête, GET dans ce cas, ainsi que le nombre et type de
paramètres, ici aucun.
Figure 3 – Classe Startup
Des attributs peuvent être utilisés pour modifier le routage par défaut et organiser les contrôleurs. Ceux-ci
décorent les classes et leurs méthodes (voir figure 4). Les attributs servent aussi à spécifier le type de réponse, le
niveau d’autorisation accepté pour cette ressource (anonyme, authentifié, rôle) ainsi qu’à ajouter la validation
comme montré sur la figure par l’utilisation de l’attribut ValidateModel. Cette validation est faite avant l’exécution
de la méthode par une autre classe définie dans l’application.
Nous notons aussi l’utilisation d’une classe abstraite BaseController qui permet de récupérer les claims lors de
l’authentification. La propriété GetUserId utilisé dans la méthode GetUserRootFiles est définie dans le
BaseController et sert à récupérer l’ID de l’utilisateur sans avoir à le passer en paramètre ou à faire une requête
à la base de données.
public class Startup
{
// [...] secrets and constantes
// constructeur pour la configuration initiale
public Startup(...) { ... }
// Ajout de services au container.
public void ConfigureServices(...)
{
...
services.AddMvc();
}
// Configuration du pipeline des requêtes HTTP.
public void Configure(...)
{
...
// ajoute le middleware pour le routage
app.UseMvc();
// initialisation de Swagger pour la documentation de l’API
// initialisation de la base de données
}
}
16 | P a g e
Cette classe démontre aussi l’injection de dépendances (Dependency Injection) inclus dans le Framework en
utilisant les interfaces (IFileRepository) pour diminuer le couplage. Cette interface fait partie du package Services
et (son implémentation) permettra la communication avec la base de données en utilisant les DTO.
Figure 4 – Classe UserFolderController
Application mobile
L’application mobile a été créée à l’aide de Xamarin, en utilisant la librairie MVMM Light Toolkit pour
implémenter le patron MVVM.
MVVM Light Toolkit
Cette librairie quoique légère offre des outils puissants pour faciliter le développement en faisant usage du Service
Locator pattern (pour localiser les ViewModel et services enregistrés), Dependency Injection et ses composantes :
• RelayCommand : Cette composante implémente ICommand pour séparer la sémantique et l’objet qui
invoque la commande du code exécuté par la commande.
• Messenger : Cette composante permet au ViewModel de communiquer avec le View. Ceci est utile
lorsqu’on désire avoir un comportement sur le View qui réagit à une commande du ViewModel comme
l’affichage d’un dialogue ou toute autre changement dans l’UI.
• DialogService et NavigationService : Ces composantes permettent de facilement créer un dialogue
(information, alerte) et naviguer (changement d’activités, retour) dans l’application respectivement.
[Produces(“application/json”)]
[Route(“api/u/folders”)]
[ValidateModel]
public class UserFoldersController : BaseController
{
private readonly IFileRepository _repo;
// constructeur pour la configuration des services
public UserFoldersController(IFileRepository repo, ...) {
_repo = repo;
}
[HttpGet(“root”)]
public async Task<IActionResult> GetUserRootFiles()
{
var root = await _repo.GetRootByUserAsync(GetUserId);
return Ok(root)
}
// autres méthodes et reste de la classe
}
17 | P a g e
• DispatcherHelper : Cette composante permet de créer et gérer un thread pour le UI, permettant ainsi
à l’utilisateur de manipuler l’interface pendant l’exécution d’opérations lourdes tels que les appels à la
base de données ou à l’API.
Elle est aussi très facile à étendre en offrant des abstractions comme ViewModelBase. Cette classe joue un rôle
clé dans l’implémentation du MVVM; elle implémente ObservableObject qui permet d’observer et réagir aux
modifications apportées à un objet qui l’implémente.
Code
Le code de l’application fait beaucoup usage des partial class (absent en Java), consistant à séparer le code d’une
classe à travers plusieurs fichiers favorisant la responsabilité unique. Nous avons ainsi pour chaque activité une
classe s’occupant de récupérer et d’instancier les éléments de la page et l’autre classe pour la logique
(instanciation du ViewModel et mise en place du data-binding).
Dans certains cas le code partagé doit être exécuté différemment sur chaque plateforme. Nous implémentons
dans ces situations le patron de stratégie en créant la classe abstraite et les méthodes abstraites dans le code
partagé qui seront implémentées pour chaque plateforme.
Interface
Pour l’interface, nous avons appliqué les principes du Material Design développé récemment (2014) par
Google. En suivant ces règles nous obtenons une interface ergonomique respectant les standards Android
actuels auxquels sont habitués les utilisateurs, favorisant le UX.
Puisque ce style est encore nouveau, beaucoup de téléphones intelligents sont incompatibles (ceux utilisant une
version antérieure à Android 5.0) avec ses nombreux ajouts et modifications. Afin d’y pallier et maintenir la
compatibilité, nous utilisons la classe AppCompatActivity qui permet de graduellement utiliser une alternative
compatible avec la version en question. Nous définissons aussi un style à utiliser en cas d’incompatibilité de
sorte à conserver le même thème et que l’interface reste la plus fidèle à celle conçue et vendue au public.
Il a aussi fallu décider d’un thème (les couleurs et styles) pour l’application. De plus, pour donner vie à Scoti,
nous avons conçu un logo et un symbole. Ce dernier représente le caractère et la philosophie de l’application
et définit ses couleurs principales :
• Rouge : Symbolise la chaleur et l’agitation du social
• Bleu : Symbolise la vérité, la sécurité et la confiance associé à l’information
• Violet : Symbolise l’illumination, du savoir et la connaissance
• Vert : Symbolise l’union et la nature organique de l’univers étudiant
Des captures d’écran de l’application se trouvent en annexe.
18 | P a g e
Tests et documentation
Pour assurer le comportement des artéfacts produits et les évaluer nous avons effectué des tests tout au long
du développement. L’une des règles respectées afin d’avoir une solution répondant aux besoins est que tous les
artéfacts du logiciel proviennent des exigences explicitées dans les cas d’utilisation et du comportement décrit
par les diagrammes d’activités. Les tests encourus se divisent en 2 catégories :
• Tests fonctionnels (à la boite noire) : Ils assurent que le code est conforme aux exigences et
établissent que le logiciel est complet, précis et adéquat en fournissant une entrée afin d’évaluer si la
sortie est conforme sans se préoccuper des composantes internes du programme. Les tests sont faits
par rapport aux spécifications.
• Tests structurels (à la boite blanche) : Ils vérifient l’implémentation d’un algorithme de façon
précise et permettent d’évaluer la quantité de code non-testé ainsi que la qualité du code et sa
conformité aux standards. Les tests sont faits par rapport au code.
Pour vérifier et valider l’API, nous avons effectués une série de tests unitaires et des tests d’intégration pour
garantir son fonctionnement lorsqu’il est utilisé.
Tests fonctionnels
Nous utilisons l’outil Postman, recommandé par Microsoft et utilisé par d’autres grandes compagnies (Adobe,
Verizon, Ebay, Cisco), pour créer et exécuter nos tests sur l’API en simulant un client (consommateur de l’API).
Cet outil nous permet aussi d’automatiser les tests répétitifs.
Tous les endpoints sont ainsi testés :
1. Nous obtenons un token en appelant api/users/token avec les paramètres email, password et
recevons en retour le token et sa date d’expiration.
2. Le token est passé dans l’entête des prochaines requêtes par la paire :
Key : Authorization & Value : Bearer “token”
3. À la réception de la réponse, nous vérifions :
a. Le code de réponse (200 dans le cas d’un GET) ;
b. L’entête contient un Content-Type ;
c. Le Content-Type contient application/json ;
d. Le contenu de la réponse.
Nous vérifions également que le temps d’exécution reste inférieur à 200 ms sauf pour la première requête.
Tests à la fumée
Ces tests non-exhaustifs couvrent les fonctions majeures de la plateforme sans aller dans le détail afin de
détecter des erreurs critiques. Ci-dessous les tests courus manuellement :
19 | P a g e
• Vérifier que le programme compile et s’exécute;
• Vérifier que l’API répond sous tous les environnements : test, développement, production;
• Vérifier que l’API reçoit et exécute les requêtes
• Vérifier que la base de données est créée lors de l’exécution;
• Vérifier que l’application mobile s’ouvre;
• Vérifier que tous les widgets répondent aux interactions;
• Vérifier que l’application communique avec l’API;
• Vérifier que l’application se connecte avec Dropbox
Tests structurels
Tous les tests fonctionnels ne valent rien sans vérifier les composantes du programme car plusieurs erreurs
pourraient s’annuler pour résulter sur un faux positif ou un faux négatif. Pour effacer ce doute, nous avons eu
recours à des tests unitaires.
Test unitaires
Les tests unitaires ont été réalisés avec le Framework XUnit. Pour organiser notre solution, ces tests sont
localisés dans un différent projet (autre paquet), ScotiAPI.Tests. Chaque test unitaire s’assure de tester une
seule composante de l’API en utilisant le style AAA :
• Arrange : section du test initialisant les objets utilisés par la méthode à tester. Nous utilisons des mock
pour simuler le contexte et les repository.
• Act : section où l’on invoque la méthode testée avec les paramètres créés précédemment.
• Assert : section vérifiant que la méthode produit le comportement désiré. Nous vérifions le contenu
et type de la réponse en les comparant avec des résultats connus d’avance.
La figure 5 ci-dessous est un test unitaire vérifiant que la méthode retourne le code d’erreur 404 et son message
si l’ID passé en paramètre n’est pas présent dans la base de données.
Tous les tests sont exécutés après chaque modification dans le code afin de s’assurer de ne rien briser et de
toujours respecter les exigences. Nous avons, comme pour toute partie du code, optimisé les tests en factorisant
certaines fonctions répétitives comme la création d’un contexte utilisé pour l’authentification et des constantes.
20 | P a g e
Figure 5 – Test unitaire GetUniversity_ReturnsHttpNotFound
Nous effectuerons par la suite des tests d’intégration pour s’assurer que toutes les composantes collaborent
bien ensemble dans un environnement similaire à celui où sera exécuté le code.
Documentation
La documentation a été rédigée tout au long du projet à l’aide des librairies StyleCop et Swagger.
StyleCop est un outil d’analyse statique de programmes de Microsoft qui applique les bonnes
pratiques du .NET Framework Design Guidelines. Il vérifie entre autres la documentation du code, les
conventions de nommage, l’ordre d’apparition (propriétés, constructeurs et méthodes) dans une classe, la
lisibilité (espace, longueur des lignes) et la maintenabilité. Il peut aussi être reconfiguré.
La documentation de l’API a été rédigée grâce à Swagger, l’une des solutions les plus populaires sur le
marché et recommandée par Microsoft. Son application au .NET Core, Swashbuckle.AspNetCore crée la
documentation à partir du routage mise en place, des controllers et modèles utilisés. Il traite aussi les attributs
ainsi que les commentaires formatés en XML. Ceci permet de déterminer les différents résultats et entrées de
chaque endpoint, les paramètres acceptés et leur attributs (optionnel, obligatoire, minimum), le type de réponse
(JSON, XML) et le niveau d’autorisation.
public class UniversitiesControllerTests
{
[Fact]
public async Task GetUniversity_ReturnsHttpNotFound()
{
// ARRANGE
int universityId = 12;
// Mock le repository servant à récupérer une université dans la base de données
var m_universityRepo = new Mock<IUniversityRepository>();
m_universityRepo.Setup(repo => repo.GetByIdAsync(universityId))
.Returns(Task.FromResult((UniversityDTO)null));
var controller = new UniversityController(m_universityRepo.Object);
// ACT
var result = await controller.GetUniversity(universityId);
// ARRANGE
var notFoundResult = Assert.IsType<NotFoundObjectResult>(result);
var returnValue = Assert.IsType<ErrorResultDTO>(notFoundResult.Value);
Assert.Equal(“University not found”, returnValue.Summary);
}
// autres méthodes et reste de la classe
}
21 | P a g e
Conclusion
Ce projet nous a permis de vivre dans sa totalité la réalisation d’une idée. Il a fallu d’abord la transformer en
projet en identifiant le problème auquel nous nous attaquons et les besoins à combler. Mettre sur pied une
solution n’était pas évident car le domaine du concept est vaste donnant lieu à beaucoup de fonctionnalités qu’il
a fallu trier. Le projet a demandé aussi un travail de recherche considérable pour la validation des besoins
des étudiants, l’approche proposée et l’étude des pratiques de l’industrie pour les différentes composantes de la
plateforme.
Nous sommes arrivés à implémenter la solution de la base de données jusqu’à l’interface de l’application mobile
mais il reste encore du travail avant le déploiement d’une première version. En plus des quelques scénarios non
couverts par l’application actuelle, il nous faut faire des tests d’intégration mais aussi des tests d’utilisabilité pour
valider le produit.
Ce projet a été une grande aventure et m’a permis d’acquérir une bonne expérience dans le développement de
logiciels en général et avec les outils (de développement) Xamarin et ASP.NET Core.
L’aventure se poursuivra durant la prochaine session
Remerciements
Il est important de mentionner que ce projet n’aurait pas vu le jour aussi tôt sans le support de l’Université de
Montréal et plus précisément des professeurs Dr. Eugene Syriani, PhD, qui a supervisé et fourni une
précieuse aide durant le développement et Dr. Sylvie Hamel, PhD qui chapeaute ce cours et a accepté de me
laisser poursuivre ce projet pendant la session.
22 | P a g e
Bibliographie
AltexSoft. (2017, Juin 26). The Good and The Bad of Xamarin Mobile Development. Récupéré sur AltexSoft:
https://www.altexsoft.com/blog/mobile/the-good-and-the-bad-of-xamarin-mobile-development/
Booch, G., Rumbaugh, J., & Jacobson, I. (1998). The Unified Modeling Language User Guide. Massachusetts:
Addison Wesley.
Cheung, H. (2015, Mars 16). Mobile App Performance Redux. Récupéré sur Medium:
https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976
East, R. (2008, Août 9). Overview of the ModelView – ViewModel (MVVM) pattern and data-binding. Récupéré sur
Russell East's blog: https://russelleast.wordpress.com/2008/08/09/overview-of-the-modelview-
viewmodel-mvvm-pattern-and-data-binding/
IBM. (2017, Juin 20). Utilisez des API REST dans vos projets web. Récupéré sur OpenClassrooms:
https://openclassrooms.com/courses/utilisez-des-api-rest-dans-vos-projets-web/pourquoi-rest
Kukic, A. (2017, Janvier 10). Alternatives to Native Mobile App Development. Récupéré sur Auth0:
https://auth0.com/blog/alternatives-to-native-mobile-app-development/
Lafontant, L.-E., & Erfanian, M. (2016, Mai 3). Toodle. Récupéré sur Github:
https://github.com/henrikeU/Toodle
Martin, C. R., & Martin, M. (2006). Agile Principles, Patterns, and Practices in C#. Prentice Hall.
Microsoft. (2016, Juillet 13). API design. Récupéré sur Microsoft Azure: https://docs.microsoft.com/en-
us/azure/architecture/best-practices/api-design
NCS News. (2016, Septembre 19). The New Reality for College Students: Earning a Bachelor’s Degree Takes 5 to 6 Years
and Students Attend Multiple Institution. Récupéré sur National Student ClearingHouse:
https://nscnews.org/the-new-reality-for-college-students-earning-a-bachelors-degree-takes-5-to-6-
years-and-students-attend-multiple-institutions/
Olesen, J. (s.d.). Color Meanings – Learn about Colors and Symbolism. Récupéré sur Color-Meanings.com:
http://www.color-meanings.com/
Reactor. (2015, Juin 24). The beginner's Guid to PhoneGap. Récupéré sur ReactorApps:
https://reactorapps.io/blog/beginners-guide-to-phonegap/
Sahni, V. (2015, Août 12). Best Practices for Designing a Pragmatic RESTful API. Récupéré sur Vinay Sahni:
http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
23 | P a g e
Schneidenbach, S. (2016, Février 24). RESTful API Best Practices and Common Pitfalls. Récupéré sur Medium:
https://medium.com/@schneidenbach/restful-api-best-practices-and-common-pitfalls-
7a83ba3763b5
Smith, K. (2013). Color Meaning, Symbolism and Psychology. Récupéré sur Sensational Color:
http://www.sensationalcolor.com/category/color-meaning/color-meaning-symbolism-psychology
Wodehouse, C. (2016, Décembre 6). Native vs. Xamarin: Which Type of Mobile App Should You Develop? Récupéré
sur Upwork: https://www.upwork.com/hiring/development/native-vs-xamarin/
Wodehouse, C. (2016, Novembre 29). Xamarin vs. PhoneGap: Which Cross-Platform Mobile App Software is Right for
You? Récupéré sur Upwork: https://www.upwork.com/hiring/mobile/xamarin-vs-phonegap-which-
cross-platform-mobile-app-software-is-right-for-you/
YoruNoHikage. (2016, Avril 7). La théorie REST, RESTful et HATEOAS. Récupéré sur zestedesavoir:
https://zestedesavoir.com/tutoriels/299/la-theorie-rest-restful-et-hateoas/
Zolciak, A. (2017, Mars 16). Why is Xamarin Vs. Cordova the Wrong Question to Ask? Récupéré sur Insane LAB:
https://insanelab.com/blog/mobile-development/xamarin-vs-cordova-cross-platform-
development/
24 | P a g e
Annexes
Annexe 1 : Cas d’utilisations
Cette annexe présente les cas d’utilisations identifiés pour ce projet. Ils ne font états que des besoins
fonctionnels. Les cas d’utilisations en vert ont été implémentés.
25 | P a g e
Annexe 2 : Modèle entités-associations
Ce diagramme présente les multiples entités présentes dans le système. Certaines entités ne sont pas présentes
dans le schéma ci-dessous par mesure de clarté.
26 | P a g e
Annexe 3 : Diagrammes d’activités UML
Ces diagrammes démontrent le flux d’activités dans 4 scénarios majeures dans l’application.
Diagramme d’activité – Login/SignUp
27 | P a g e
Diagramme d’activité - Journal
28 | P a g e
Diagramme d’activité – Question
29 | P a g e
Diagramme d’activité - Fichiers
30 | P a g e
Annexe 4 : Diagramme de paquets
Stabilité et abstraction des paquets
Mesure d’instabilité d’un paquet :
• Ce : nombre de dépendances sortantes
• Ca : nombre de dépendances entrantes
• 𝐼 = 𝐶𝑒
𝐶𝑎+𝐶𝑒
Mesure d’abstraction d’un paquet :
• NC : nombre de classes total dans le paquet
• NA : nombre de classes abstraites dans le paquet
• 𝐴 = 𝑁𝐴
𝑁𝐶
𝐷 = |𝐴 + 𝐼 − 1|
Idéalement, D = 0
31 | P a g e
Annexe 5 : Application mobile
32 | P a g e
Recommended