i

Université de Montréal Département d’informatique et de recherche opérationnelle

Projet informatique IFT3150

Sophie Savoie 20110375

Rapport final

Projet Acclimate

présenté à

Houari Sahraoui et

Michalis Famelis

11 septembre 2018

i

TABLE DES MATIÈRES

1. Présentation sommaire du projet ......................................................................................................... 1

2. Principales fonctionnalités .................................................................................................................... 2

3. Architecture du projet .......................................................................................................................... 2

4. Équipe ................................................................................................................................................... 3

5. Technologies utilisées ........................................................................................................................... 3

6. Architecture du serveur ........................................................................................................................ 4

6.1 Spring framework.......................................................................................................................... 4

6.2 Communications entre le serveur et l'application ........................................................................ 4

6.3 REST API ........................................................................................................................................ 5

7. Base de données (BDD) ......................................................................................................................... 5

7.1 Relations entre les tables .............................................................................................................. 6

7.2 Module d’alertes ........................................................................................................................... 7

Source des données d’alertes ............................................................................................................... 7

Acquisition et mise à jour des données alertes .................................................................................... 8

7.3 Module des utilisateurs ................................................................................................................ 9

7.4 Module des zones surveillées ....................................................................................................... 9

7.5 Module des tuiles ........................................................................................................................ 10

7.6 Envoi des notifications aux usagers ............................................................................................ 10

7.7 Formatage des bases de données serveur.................................................................................. 10

8. Bilan des réalisations .......................................................................................................................... 10

9. Objectifs réalisés ................................................................................................................................. 11

9.1 Refactoring .................................................................................................................................. 11

9.2 Bases de données........................................................................................................................ 11

10. Pistes d’amélioration ...................................................................................................................... 11

10.1 Effectuer un traitement sur la localisation des alertes ............................................................... 11

10.2 Déterminer les méthodes d’analyse ........................................................................................... 12

10.3 Lissage des polygones ................................................................................................................. 12

10.4 Ajouter de nouvelles BDD ........................................................................................................... 12

11. Principaux défis rencontrés ............................................................................................................ 12

1

INTRODUCTION

Le cours IFT 3150 vise à initier les étudiants à la recherche par la réalisation d’un projet informatique

d’ampleur. Dans le cadre de ce cours, l’application Acclimate a été développée dans le but d’informer les

citoyens du Québec des alertes climatiques et environnementales qui les concernent. Le projet a vu le

jour lors du Hackathon Hack-Qc 2018, durant lequel une première version de l’application a été

développée. Acclimate a d’ailleurs remporté le 3e prix de la compétition (https://hackqc.ca/).

Les principaux objectifs du projet informatique étaient de développer un maximum de fonctionnalités

dans la période de temps prescris et de tendre vers une application qui soit disponible au public. Trois

personnes participaient au projet : Jérémi Grenier-Berthiaume, Olivier Lepage-Applin et moi-même. Ma

partie du travail concernait spécifiquement la partie serveur de l’application. Les grands objectifs du

serveur étaient de créer et de gérer les bases de données, de créer des requêtes pour communiquer avec

le client, ainsi que de gérer la logique de l’application.

Le présent rapport vise à documenter le travail réalisé dans le cadre du cours et à dresser un bilan des

objectifs de départ. En premier lieu, une présentation de l’application et du serveur sera réalisée, pour

ensuite présenter les résultats obtenus, puis terminer avec des pistes d’amélioration.

1. Présentation sommaire du projet

Acclimate vise à informer les citoyens québécois des alertes climatiques et environnementales via une

plateforme web et une application Android. L’application permet de visualiser la localisation d’alertes

actuelles et historiques visant l’ensemble du territoire du Québec.

Figure 1- Design général de l'application web et de l'application Android

2

On distingue quatre principales catégories d’alertes dans l’application, soient des alertes reliées à :

- L’eau : inondations, suivi des cours d’eau

- Le feu : feu de forêt, incendie

- La terre : tremblement de terre, glissement de terrain

- La météo : averses, vents puissants, smog et pollution de l’air, grêle, etc.

Les alertes actuelles proviennent de sources officielles telles que le Ministère de la Sécurité publique du

Québec et la Sopfeu, ou des usagers de l’application. Les deux types d’alertes sont distinguées dans

l’application par le biais d’un design différent afin que les utilisateurs puissent rapidement les différencier.

Figure 2 - Épingles d'alertes officielles Figure 3 - Épingles d'alertes usager

2. Principales fonctionnalités

Les principales fonctionnalités de l’application implémentées jusqu’à présent permettent de :

- Visualiser les alertes sur la carte : tout type d’utilisateur peut ouvrir la carte et voir la localisation

des alertes actuelles et historiques.

- Déclarer des alertes : les usagers authentifiés ont la possibilité de déclarer des alertes autour

d’eux.

- Recevoir des notifications pour des zones surveillées : les usagers authentifiés peuvent enregistrer

des zones surveillées circulaires ou rectangulaires afin d’être notifiés de toute alerte déclarée

dans ces zones.

- Modifier le pointage des alertes usager : ajouter un point au score si l’usager confirme l’alerte ou

en enlever un s’il considère l’alerte non fondée.

3. Architecture du projet

Acclimate possède une architecture de type trois tiers, composées des couches suivantes :

- Serveur : gère la logique de l’application et fait le lien entre le client et les bases de données

- Bases de données : stockage et accès aux données persistantes de l’application

- Clients (web et Android) : affichage sur les appareils mobiles et le site web et interaction avec

l’utilisateur

Les couches du serveur et du client communiquent entre elles par le biais de requêtes HTTP. Le modèle

trois tiers possède plusieurs avantages, incluant :

- L’allègement du client, ce qui améliore la performance de l’application et réduit l’utilisation de la

batterie du téléphone mobile

3

- L’amélioration de la sécurité des données, en ayant aucun lien direct entre le client et les données

- Une plus grande prise en compte des différentes plateformes, en ayant un client spécifique pour

chacune d’elle.

4. Équipe

Lors du hackathon, l’équipe était composée de 5 membres, dont les principales tâches étaient :

- Charles-Philippe Lepage : design général de l’application, développement d’une première version

de la plateforme web

- Jérémi Grenier-Berthiaume : implémentation de l’UI et du front-end de l’Application Android

- Olivier Lepage-Applin : développement du back-end de l’application mobile et gestion des

communications avec le serveur.

- Normand Desmarais : développement du back-end côté serveur et gestion des bases de données

- Sophie Savoie : développement du back-end côté serveur et gestion des bases de données

Seulement 3 de ces membres ont choisi de poursuivre le projet dans le cadre du cours Projet informatique

IFT 3150, c’est-à-dire Jérémi Grenier-Berthiaume, Olivier Lepage-Applin et moi-même. Jérémi et Olivier

assuraient le développement de du côté client, alors que je m’occupais du serveur et des bases de

données.

5. Technologies utilisées

La plateforme web a été développé en JavaScript, tandis que l’application mobile et le serveur utilisent le

langage Java.

Du côté de l’application mobile :

- Android Studio est utilisé pour la gestion de l’affichage sur l’application mobile.

- Firebase assure la gestion des authentifications.

- OSMDroid est employé par la carte de l’application.

Du côté de l’application web :

- Angular JS est derrière le développement du Frontend

- OpenLayer est utilisé pour la carte interactive

Du côté serveur :

- Spring est utilisé pour le framework du back-end de l’application

Du côté des bases de données :

- MySQL est employé pour la sauvegarde des bases de données

4

6. Architecture du serveur

L’architecture du serveur est essentiellement basée sur les principes de l’orienté objet, du patron modèle-

vue-contrôleur et du framework Spring. Le serveur est composé de quatre grands modules :

- Alertes

- Usagers

- Zones surveillées

- Tuiles

Chacun de ces modules est associé à une table de la base de données, à l’exception des alertes qui en

possède plusieurs. Pour chacun d’eux, nous avons minimalement les classes suivantes :

- @Entity

- @Repository

- @Service

Les classes possédant l’annotation @Entity déterminent le contenu et la structure des tables. Cette

annotation indique à Spring de créer une table dans la base de données.

Chaque classe @Entity est associée à une classe @Repository, un répertoire dans lequel il est possible de

faire des recherches, des ajouts, des suppressions ou des mises à jour.

Des classes de @Service sont utilisées pour la logique derrière les requêtes et l’accès aux répertoires.

Chaque ressource utilisée du côté client possède un @RestController, c’est-à-dire une classe dans laquelle

sont implémentées les requêtes. Ainsi, les modules d’alertes, d’usagers et de zones surveillées disposent

de cette classe.

6.1 Spring framework

À la suite du Hackathon, Spring a été ajouté. Il s’agit d’un framework qui est très répandu dans le

développement d’applications Java. Spring offre de multiples fonctionnalités telles que :

- La gestion des bases de données à l’aide de JBDC et JPA, qui permettent de traduire les requêtes

SQL en Java. Ainsi, toutes les requêtes de données peuvent être rédigées en langage Java. De plus,

les tables peuvent être créées directement par les couches du modèle.

- L’abstraction de différentes technologies afin de faciliter leur développement

- Faciliter les requêtes de communication entre le serveur et le client

6.2 Communications entre le serveur et l'application

Les communications entre le serveur et l’application sont envoyées en format JSON. Lors du Hackathon,

la transformation en JSON était effectuée manuellement. Lors de l’intégration de Spring du côté serveur,

une conversion automatique vers le format JSON a été intégrée à l’aide de la librairie Jackson. Cela se fait

en ajoutant simplement une dépendance dans le fichier POM.XML.

5

6.3 REST API

Le REST API a aussi été intégré du côté serveur dans le but de respecter les standards de l’industrie. Il

s’agit d’une architecture basée sur le protocole HTTP. Les requêtes sont effectuées sur l’URI de la

ressource demandée, puis la réponse est transférée sous format JSON. Plusieurs opérations sont

supportées par cet API.

- GET : retourne des objets de la base de données

- PUT : remplace un objet dans la base de données ou le crée s’il n’existe pas

- POST : crée un nouvel objet dans la base de données

- PATCH : modifie un objet de la base de données

- DELETE : efface un objet de la base de données.

Acclimate utilise l’ensemble de ces opérations à l’exception du PUT. Des requêtes ont été implémentées

pour :

- les alertes

- les zones surveillées

- les usagers.

Le client a accès aux différentes méthodes HTTP en ajoutant simplement le type de méthode dans

l’entête.

À l’aide d’un GET, le client peut obtenir un objet spécifique en effectuant avec un identifiant spécifique

ou obtenir l’ensemble d’une collection lorsqu’aucun identifiant n’est spécifié.

Avec le PATCH, il peut effectuer mettre à jour un objet en envoyant les champs et l’identifiant de l’instance

à modifier.

Avec le POST, le client peut créer un nouvel objet en envoyant une instance de celui-ci, par exemple lors

de la création d’un nouvel utilisateur ou lors de l’ajout d’une nouvelle zone surveillée.

Avec le DELETE, le client peut supprimer un ou des objets de la base de données, par exemple un usager

ou les zones surveillées d’un usager.

Dans chaque réponse du serveur, Un code HTTP est envoyé afin d’indiquer le succès (code 200) ou l’échec

de l’opération. En cas d’échec, le code approprié est envoyé (4XX erreur client, 5XX erreur serveur), en

plus d’un message fournissant un peu plus d’explications sur la nature de l’échec.

Une authentification peut également être ajoutée dans l’entête de la requête. Dans le cas d’Acclimate, le

«idToken» généré par Firebase lorsqu’un utilisateur s’authentifie sur l’application est ajouté par le client

dans l’entête des requêtes. Le serveur extrait l’identifiant de l’utilisateur à partir de l’«idToken» pour ainsi

vérifier la validité de l’utilisateur et sécuriser les requêtes.

7. Base de données (BDD)

Lors du Hackathon, aucune donnée n’était persistante. L’ajout d’une base de données était donc

nécessaire, afin de stocker les données d’Acclimate de façon permanente. Celle-ci est formée de

différentes tables, telles que :

6

- LiveAlert

- UserAlert

- HistoricalAlert

- OldUserAlert

- User

- MonitoredZone

- Tile

Figure 4 - diagramme entité-relation de la base de données

7.1 Relations entre les tables

Le diagramme des bases de données indique qu’il existe des liens relationnels entre certaines tables. Il

existe d’abord une relation one-to-many entre la table des usagers et la table des alertes usager. En effet,

7

un usager peut créer une ou plusieurs alertes. Ainsi, l’alerte stocke le «id» de l’usager via cette relation.

Même principe entre l’usager et les zones surveillées, car ce dernier peut en posséder une ou plusieurs. Il

existe également une relation one-to-many entre les zones surveillées et les tuiles.

Les trois relations one-to-many sont unidirectionnelles. C’est donc la classe enfant qui possède

l’identifiant de la classe parent qui lui est associée. Par exemple, dans le cas des zones surveillées, c’est

seulement du côté des tuiles que l’on stocke la clé primaire des zones surveillées, soit son champ «id».

Les relations sont gérées directement dans les classes du modèle. On peut voir une annotation Many-to-

one au-dessus de l’objet qui figure dans l’objet enfant. C’est également à cet endroit que l’on indique quel

champ de l’objet sera inséré dans la table, par exemple la clé primaire l’objet.

7.2 Module d’alertes

Le module d’alertes est celui qui possède l’architecture la plus complexe. On distingue trois principales

catégories d’alertes :

- «LiveAlert» : alertes en temps réel provenant d’autorités gouvernementales

- «UserAlert» : alertes déclarées par les utilisateurs de l’application

- «HistoAlert» : alertes historiques provenant de bases de données historiques gouvernementales,

d’anciennes alertes en temps réel ou d’anciennes alertes usager dont le niveau de certitude est

suffisamment élevé pour être considéré «observée».

Ainsi, une classe abstraite d’alerte a été créée, de laquelle héritent les différents types d’alertes. Cette

architecture permet à la fois d’avoir une structure partagée, mais aussi d’ajouter des spécificités à chaque

alerte.

Dans le cas des alertes, comme elles héritent d’une classe abstraite, il a fallu créer un répertoire général

d’alerte @NoRepository non instancié duquel héritent des répertoires @Transactional, c’est-à-dire des

répertoires concrets qui sont associés aux différents types d’alertes.

Chaque type d’alerte possède son propre répertoire. Cela a été conçu ainsi afin de rendre les recherches

dans les tables plus efficaces. Aussi, chaque type d’alerte possède ses particularités. Par exemple, l’alerte

usager possède un champ «uId» dans lequel est stocké l’identifiant de l’utilisateur ayant créé l’alerte. Par

contre, tous les champs en commun se trouvent dans la classe abstraite «Alerte», évitant ainsi la

répétition de code. Un répertoire «OldUserAlert» a également été créé pour stocker les alertes d’usagers

qui n’ont pas atteint le seuil de certitude requis pour être ajouté dans le répertoire des alertes historiques.

Ainsi, ces alertes sont conservées mais ne peuvent être visualisées sur la carte de l’application.

Source des données d’alertes

Les alertes «live» proviennent de sources officielles. Elles contiennent actuellement deux bases de

données :

1. Carte de vigilance multirisque - fil de situation RSS (points)

Cette base de données provient du site des données ouvertes du Québec. Elle a été développée par

le ministère de la Sécurité publique du Québec (MSP). Elle regroupe des avertissements sur des

8

phénomènes naturels et elle est mise à jour en continu et rendue disponible sous forme de flux rss

(https://geoegl.msp.gouv.qc.ca/avp/rss/).

2. Incendies en activité de la zone intensive et nordique

Les données sur les incendies en activité sont disponibles directement sur le site internet de la Société

de protection des forêts contre le feu (SOPFEU) (http://sopfeu.qc.ca/).

Les alertes historiques proviennent de plusieurs sources. Il s’agit d’abord d’alertes courantes et d’alertes

usagers qui ne sont plus à jour, auxquelles sont ajoutées des bases de données officielles d’alertes

historiques. Le répertoire contient actuellement une seule base de données historique

1. Historique des événements de sécurité civile – Archives

Cette base de données est disponible sur le site des données ouvertes du Québec. Elle regroupe de

l’information reliée aux sinistres passés en lien avec la sécurité civile. Elle est mise à jour en continu

par le ministère de la sécurité publique du Québec

(https://www.donneesquebec.ca/recherche/fr/dataset/observations-terrain-historiques-

devenements-archives).

Acquisition et mise à jour des données alertes

Un système de mise à jour a été implémenté pour chaque type d’alerte, en fonction de leur source, de

leur format et de leur fréquence de mise à jour.

Alertes live

Les alertes en temps réel du Ministère de la Sécurité publique proviennent d’un flux Rss qui est mis à jour

par le Ministère de la sécurité publique à toutes les deux minutes. Ainsi, à cette même fréquence, le flux

est analysé puis les alertes sont extraites du flux.

Les alertes de feu du site internet de la Sopfeu sont contenues dans un script JavaScript. Un outil capable

de recueillir le contenu du script était donc requis pour cette tâche. La librairie Selenium a été utilisée. Elle

est capable de naviguer dans le contenu de la page et cliquer sur les boutons déclenchant l’affichage des

listes d’alertes puis, une fois les alertes téléchargées sur la page, elle récupère les champs des alertes en

sélectionnant les balises html appropriées. Ces alertes sont mises à jour en même temps que celles de la

MSP, ce qui simplifie largement le code car ces deux bases de données sont enregistrées dans le même

répertoire et plusieurs étapes de leur processus de mise à jour sont semblables.

Pour les deux bases de données, les alertes recueillies sont ensuite comparées au contenu de la base de

données d’Acclimate. Comme elles contiennent toutes deux un identifiant unique, la comparaison de ce

champ est suffisante pour savoir si l’alerte est déjà contenue dans le répertoire. Lors de la mise à jour :

- S’il y a de nouvelles alertes, elles sont ajoutées dans la base de données

- Si certaines alertes de la base de données ne sont plus à jour, elles sont envoyées vers la base de

données historiques.

Alertes usagers

Les nouvelles alertes usager sont ajoutées par la réception d’une requête de type POST de la part du client

de l’application.

9

À chaque heure, une mise à jour des alertes usager est réalisée. Si une alerte usager est présente depuis

plus de 24 heures, elle est retirée de la table des alertes usager. Puis, en fonction du niveau de certitude

que l’alerte a acquis :

- Si le niveau de certitude est « observé », c’est-à-dire que son score est d’au moins 10 points,

l’alerte est enregistrée dans la table des alertes historiques.

- Si le niveau de certitude n’est pas suffisant, l’alerte est conservée sous forme de «OldUserAlert»

dans le répertoire «OldUserAlertRepository».

Lorsqu’un utilisateur est supprimé de la base de données, les alertes qu’il avait créées s’effacent au même

moment, à part si ces alertes ont été transférées dans le répertoire des alertes historiques.

Alertes historiques

Les alertes historiques sont mises à jour une fois par semaine, à chaque dimanche minuit. Le fichier des

alertes historiques est ainsi récupéré du site web des données ouvertes, puis enregistré en format CSV.

Ensuite, le contenu de la table est extrait du document sous forme de String à l’aide d’un

«BufferedReader», pour ensuite être divisé en tableau de String en effectuant un «Split» sur les virgules.

Le contenu des différents champs du document devient alors disponible pour créer les alertes. Lors de

l’extraction des différents champs, la date de mise à jour est évaluée avant d’enregistrer l’alerte :

- Si une alerte date de plus d’une semaine, elle est ignorée.

- Sinon, elle est enregistrée dans la table des alertes historiques.

7.3 Module des utilisateurs

Une table pour les usagers de l’application a été créée. Comme les authentifications sont réalisées à l’aide

de Firebase, la table des usagers est plutôt épurée. Elle ne contient aucune donnée sensible comme un

mot de passe ou une adresse.

L’ajout et la mise à jour des données des usagers est réalisé par l’entremise de requêtes qui sont envoyées

au serveur par la partie client de l’application.

7.4 Module des zones surveillées

Une table a été créée pour les zones surveillées des utilisateurs, ou «Monitored Zones». Deux types de

zones sont disponibles aux usagers. Le premier est un rectangle, qui est créé en appuyant directement sur

la carte. Le second est un cercle. Le cercle possède une paire de coordonnées associées au centre, puis un

rayon. Ce type de zone est utile pour un usager qui souhaite par exemple surveiller une adresse donnée

comme sa maison ou son chalet.

Les zones surveillées sont créées par les usagers. Lorsqu’une zone est créée, mise à jour ou supprimée, la

requête appropriée est envoyée au serveur, qui s’occupe de modifier la base de données en conséquence.

Par ailleurs, si un utilisateur est effacé de la base de données, l’ensemble de ses zones surveillées sont

effacées au même moment.

10

7.5 Module des tuiles

Une table de tuiles a aussi été créée dans le but de rendre la gestion des notifications plus efficace. Les

tuiles découpent le territoire du Québec à chaque degré du Nord au Sud et de l’Ouest à l’Est. La superficie

de chaque tuile est donc d’un degré au carré.

Lors de la création d’une zone surveillée par un utilisateur, le serveur calcule dans quelles tuiles est située

la zone surveillée et enregistre cette information dans la table des tuiles. Il est donc possible par la suite

d’aller sélectionner les zones surveillées d’une tuile précise.

7.6 Envoi des notifications aux usagers

Lorsqu’une mise à jour des alertes courantes est effectuée, une méthode est lancée pour recueillir la liste

des tuiles dans lesquelles sont localisées les alertes. Pour chaque nouvelle alerte, un simple calcul

mathématique permet de savoir dans quelle tuile est située une alerte. Puis, pour chaque tuile, nous

allons sélectionner les zones qui s’y trouvent. Enfin, il ne reste plus qu’à vérifier si ces zones contiennent

les alertes. Si c’est le cas, une notification est envoyée à l’utilisateur concerné.

7.7 Formatage des bases de données serveur

Les alertes ont été formatées de manière à avoir les mêmes champs, mis à part l’alerte usager qui contient

quelques champs en plus. Les champs des alertes du Ministère de la Sécurité publique ont été sélectionnés

comme étant les noms de champs officiels de nos alertes. Ainsi, cela permet d’afficher les alertes de façon

uniforme et simplifie beaucoup le code.

8. Bilan des réalisations

Au début du cours Projet Informatique, des objectifs ont été établis en équipe pour chacune des couches

de l’application. De manière générale, mes objectifs dans le cadre du cours Projet informatique étaient

de poursuivre le développement du back-end de l’application du côté serveur. Voici la liste des objectifs

du côté serveur avec leur état d’avancement actuel. Ces objectifs seront détaillés par la suite.

Objectif État d’avancement

1. Refactoring

1.1 Formatage des communications JSON entre le serveur et l'application Réalisé

1.2 Classes Alertes Réalisé

1.3 Classes BDD afin de faciliter l'ajout de bases de données Réalisé

2. Base de données (BDD)

2.1 Implémenter un système qui permet la mise à jour périodique des bases de données sur le serveur

Réalisé

2.2 Ajouter de nouvelles BDD En cours

2.3 Implémenter une BDD pour la gestion des comptes utilisateurs Réalisé

2.4 Implémenter une BDD pour la gestion des alertes courantes avec MySQL ou NoSQL

Réalisé

2.5 Implémenter une BDD pour la gestion de l'historique des alertes Réalisé

2.6 Formatage des bases de données serveur Réalisé

11

Objectif État d’avancement

3. Alertes

3.1 Effectuer un traitement sur la localisation des alertes (ex : Étendre pour rivières)

À faire

3.2 Déterminer les méthodes d’analyse À faire

3.3 Gérer la durée des alertes usagers Réalisé

4. Lissage des polygones À faire

9. Objectifs réalisés

La plupart des objectifs fixés au départ ont été réalisés, soit neuf sur treize, et un objectif est en cours de

réalisation.

9.1 Refactoring

Acclimate a été initié lors d’un Hackathon. Lors de cet événement, l’objectif était de livrer une version

fonctionnelle en 48h. Ainsi, l’architecture de l’application n’avait pas été conçue de façon optimale et un

travail de refactorisation était nécessaire par la suite afin de mieux structurer le code et le rendre plus

maintenable. Ce travail a donc été entrepris à la suite du Hackathon et a mené à une communication

standardisée entre le serveur et l'application, à une structure efficace des différentes classes d’alertes et

des bases de données en général à l’aide du framework Spring.

9.2 Bases de données

Les données de l’application sont maintenant persistantes. Un système de mise à jour a également été

implémenté pour chacune des bases de données. Des tables ont été créées pour les utilisateurs, les

alertes, les zones surveillées et les tuiles. Une nouvelle base de données a également été intégrée dans

l’application, soit les incendies en activité de la SOPFEU.

10. Pistes d’amélioration

Quelques objectifs demeurent à réaliser, ils le seront donc après la fin du cours Projet informatique.

10.1 Effectuer un traitement sur la localisation des alertes

Comme les alertes officielles sont présentées sous forme de point, la précision quant à l’emplacement de

l’alerte ne semble pas toujours optimale lorsqu’elles concernent une région. Par exemple, lorsqu’une

rivière est à risque d’inondation, le point de l’alerte est placé au centre de la rivière. Pourtant, si

l’inondation concerne toute la rivière, il faudrait que les personnes qui possèdent des zones surveillées

tout au long de cette rivière soit notifiés. Il s’agit d’une fonctionnalité qui n’a pas encore été implémentée,

mais qui devrait l’être dans le futur.

12

10.2 Déterminer les méthodes d’analyse

Les alertes pourraient être analysées statistiquement afin de dresser différents portraits du territoire

québécois. Cela nous permettrait par exemple d’afficher les régions les plus à risque en fonction des

différents types d’alertes.

10.3 Lissage des polygones

L’ajout de bases de données de type polygones a été testé. L’application n’était pas en mesure d’afficher

les polygones en raison du très grand nombre de points contenus dans chacun d’eux. L’objectif dans le

futur est donc de lisser les polygones en fonction du zoom. Ainsi, lorsque l’on est très rapproché de la

carte, le polygone afficherait plus de détails que lorsque l’on serait plus éloigné. Des lectures ont été faites

sur le sujet et la librairie «GeoTools» (http://geotools.org/) de Java semblerait en mesure de le faire.

Cependant, le temps a manqué pour implémenter cette fonctionnalité.

10.4 Ajouter de nouvelles BDD

Il est souhaité d’ajouter de nouvelles bases de données d’alertes dans l’application, afin que l’ensemble

des bases de données ouvertes qui concernent les alertes actuelles et historiques soient contenues dans

l’application.

11. Principaux défis rencontrés

Ce projet a été l’occasion de travailler avec de nouvelles technologies telles que Spring et MySQL. Il

s’agissait d’un défi de taille et beaucoup de lectures et de tests ont été nécessaires pour en arriver à des

résultats satisfaisants. Spring est un outil puissant qui, lorsque maîtrisé, permet d’économiser beaucoup

de temps en raison des nombreuses fonctionnalités qu’il offre. Cependant, Spring demande un certain

temps pour comprendre l’architecture des classes et les nombreuses annotations à utiliser.

L’utilisation de MySQL sans cours en bases de données en poche a également comporté son lot de

complexité. L’architecture de la base de données a été l’aspect le plus difficile à réaliser. Spring aura été

d’une grande aide car il permet d’abstraire les requêtes SQL et les traduire en requêtes Java. Par ailleurs,

le fait que les tables aient beaucoup évolué au long du projet a apporté de nombreuses difficultés. Par

exemple, des champs ont été ajoutés et d’autres supprimés. Après ces modifications, les tables devaient

souvent être recréées, puisque les requêtes devenaient non fonctionnelles.

Enfin, le manque de documentation a rendu l’apprentissage de certains outils plus difficile, notamment

Geotools. Geotools semble la librairie la plus appropriée pour manipuler des données de type polygone à

l’aide de Java. Malheureusement, la documentation disponible n’était pas suffisante pour me permettre

de maîtriser rapidement ses fonctionnalités et certains problèmes n’ont pas pu être résolus.

CONCLUSION

Le cours IFT 3150 aura été l’occasion pour toute l’équipe du projet d’approfondir ses connaissances sur

plusieurs technologies telles que Java, Spring, Android studio. Au terme du cours IFT-3150, l’application

Acclimate est maintenant une application fonctionnelle possédant de nombreuses fonctionnalités telles

que l’authentification des usagers, la consultation des alertes sur la carte, l’enregistrement de zones

13

surveillées et la déclaration d’alertes par les usagers. Le serveur possède maintenant ses propres bases

de données. Il communique maintenant avec le client à l’aide de requêtes et il assure la mise à jour de ses

données. L’application n’est pas encore rendue au stade de déploiement public, mais s’en approche à

grands pas.