université de montréal projet informatique ift3150 sophie savoie 20110375 rapport ... · 2018. 9....
TRANSCRIPT
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.