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