Proposition d'une architecture fonctionnelle

La solution proposée dans la section 4 doit être formalisée par une architecture fonctionnelle pour décrire du point de vue informatique notre système de mise à jour. Cependant, il existe plusieurs grandes familles d'architecture pour les systèmes informatiques tels que les architectures client-serveur, les architectures Standalone et les architectures SOA (Service Oriented Architecture).

L'architecture de notre système de mise à jour doit être conforme à l'une des grandes familles d'architecture et c'est l'architecture orientée service (SOA) que nous avons choisi. Le choix de l'architecture orientée service se justifie par le fait d'utiliser la participation volontaire des utilisateurs à la mise à jour de la base de données d'accessibilité en plus de la mise à jour

73

depuis des sources externes. Les deux types de mise à jour peuvent s'effectuer à partir de différents systèmes par exemple un serveur pour la mise à jour à partir des sources externes ou une application mobile (Android, iOS,…), ou encore une page web. L'architecture orientée service permet un faible couplage entre les fonctionnalités de mise à jour que nous allons implémenter et les systèmes utilisés pour la mise à jour. Donc, exposer les fonctionnalités de mise à jour de la base de données d'accessibilité à travers un service web permettra d'éviter la duplication des traitements pour chaque système qui sera utilisé. La figure suivante illustre notre architecture fonctionnelle.

Figure ‎4.9: Architecture fonctionnelle du système de mise à jour proposé

Notre solution est organisée en trois couches: une couche de présentation qui comporte l'application Web/Mobile; la couche de logique d'affaires qui contient les extracteurs, les transformateurs et le service web; et enfin une couche d'accès à la base de données d'accessibilité.

Succinctement, notre architecture fonctionnelle (figure 4.9) est composée de :

- Une couche d’extraction : regroupant un ensemble d'extracteurs, proportionnellement au nombre de sources de données. Cette couche se charge de la connexion aux différentes sources externes afin de récupérer les données, les stocker dans la base de données interne puis d’appeler le transformateur associé à chacune d’elle.

74

- Une couche de transformation : rassemblant un nombre de transformateurs proportionnel au nombre de fichiers à traiter. Le rôle des transformateurs est d’adapter la donnée extraite au contrat de service du service web de chargement puis de lui transmettre les résultats.

- Une application web : permettant la transmission des informations sur l’accessibilité des lieux par les collaborateurs directement au service web de chargement.

- Un service web de chargement qui est composé de deux modules :

- Un module chargé des tâches de traitement de l'information en effectuant l'analyse syntaxique et sémantique, la géolocalisation, le géocodage et la projection du système de référence. Les informations reçues par ce module peuvent provenir des transformateurs ou de tout autre système respectant le contrat de service tel que l'application pour la mise à jour participative (VGI).

- Un module de chargement qui complète le traitement en effectuant la validation des informations. Par la suite, ce module procède à la mise à jour de la base de données d'accessibilité.

L’étape d’extraction et de transformation n’est pas obligatoire si la source peut envoyer les données directement au service web tout en respectant son contrat

4.6 Conclusion

Dans ce chapitre 4, nous avons présenté les spécifications des données d'obstacles/facilitateurs afin de mieux préciser le type de données sur lesquelles nous avons travaillé. L’analyse de ces spécifications nous a amené à classer ces données spatio- temporelles en deux grandes catégories, soit des entités spatiales à évolution rapide ou à évolution lente. Nous avons aussi constaté que, indépendamment du format de stockage utilisé, la modélisation de la dimension spatiale de ces entités peut être géométrique ou non- géométrique. Ensuite, nous avons exposé trois cas d'utilisation possibles à travers la présentation des scénarios: le premier donne l'exemple de données d'accessibilité à fréquence de mise à jour connue, le deuxième décrie le cas de données d'obstacles/facilitateurs prévisibles et dont la fréquence de mise à jour est non connue, tandis que le troisième présente le cas des données d'obstacles/facilitateurs imprévisibles et dont la fréquence de mise à jour est non connue. L'analyse de ces scénarios nous a amené à déterminer les besoins et fonctionnalités utiles à notre système de mise à jour qu'on a regroupé en trois catégories: collecte, préparation et intégration des données. Finalement, nous avons proposé

75

une méthode de mise à jour automatique et en temps quasi réel des données spatio- temporelles d’accessibilité adaptée à nos besoins et une architecture fonctionnelle pour formaliser la solution proposée. En résumé, cette solution est composée d’une couche d’extraction qui répond en partie aux besoins du multi-sources et d’automatisation; une couche de transformation qui répond au besoin du multi-formats en permettant d’adapter la donnée extraite au contrat de service du service web de chargement; une application web qui offre la possibilité de transmettre des informations sur l’accessibilité des lieux par les collaborateurs en temps quasi-réel directement au service web de chargement; et enfin, le cœur de la solution, un service web de chargement qui est composé de deux modules : Le premier est chargé des tâches de traitement automatique et en temps quasi-réel de l'information reçue de multi- sources en effectuant l'analyse syntaxique et sémantique, la géolocalisation, le géocodage et la projection du système de référence le cas échéant. Puis, le deuxième complète le traitement en effectuant la validation et le contrôle d’unicité des informations à mettre à jour dans la base de données d'accessibilité avant de procéder au chargement.

77