Embed Size (px)
Citation preview
RAPPORT TECHNIQUE PRÉSENTÉ À L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE
DANS LE CADRE DU COURS GTI795/LOG795 PROJET DE FIN D'ÉTUDES EN GÉNIE DES TI
PROTOGEST
PFE 025 - DOODLE POUR AVOCATS
ALEXIS LEMELIN-POULIN LEMA14109400
SIMON ETHIER ETHS26099307
ANTHONY CORRIVEAU CORA06069107
WALID BEZZAOUI BEZW14129104
DÉPARTEMENT DE GÉNIE LOGICIEL ET DES TI
Professeur-superviseur
Alain April
MONTRÉAL, 14 AOÛT 2018
ÉTÉ 2018
A.LEMELIN-POULIN, S. ETHIER, A. CORRIVEAU, W. BEZZAOUI
2
Remerciements
L’équipe du projet de fin d’études aimerait remercier chaleureusement les personnes suivantes
qui ont joué un rôle clé dans la réalisation du projet de fin d’études. Tout d’abord, nos
remerciements s’adressent à Frank Calendriello, le promoteur du projet, pour son soutien lors
de la conception de la solution. Ses connaissances et son expertise dans le domaine juridique
ont été fort utiles et nous ont permis d’affiner nos objectifs et guider le développement.
Nous tenons également à remercier le professeur Alain April. Il nous a rencontrés de façon
hebdomadaire tout au long du projet. Il nous a guidés pour le choix technologique de la solution.
De plus, il nous a aidés à développer une suite d’objectif cohérent et réalisable dans le cadre
du cours. Ses conseils ont été appréciés à chaque décision critique du projet.
3
PROTOGEST
PFE 025 - DOODLE POUR AVOCATS
Résumé
Le client, Frank Calandriello, est un avocat fondateur de la firme Cucciniello Calandriello
Attorneys Inc. Il doit suivre les procédures de la Cour du Québec et du Canada afin de présenter
le cas de ses clients en cour provinciale et fédérale.
Le défi principal est d’optimiser le temps consacré aux tâches de coordination requises par les
procédures de protocoles d’instances mises en place par les cours provinciales et fédérales.
Les objectifs principaux de ce projet de fin d’études sont : De comprendre les exigences et de
produire un document de vision; identifier une technologie libre pour effectuer le prototypage
du logiciel; effectuer la conception et la réalisation d’un premier prototype logiciel. Ce prototype
servira de preuve de concept et permettra de 1) remplir les documents demandés par la cour
plus efficacement et 2) améliorer la planification des dates de chaque évènement entre les
différents intervenants. Le document de vision que nous avons produit peut être retrouvé en
cliquant sur le lien de la référence 10 de ce document. Il y est enregistré sous le nom Protogest-
vision.docx.
4
Table des matières
Page
Objectifs .................................................................................................................................................................... 9 Présentation du promoteur ...................................................................................................................................... 9
Architecture existante .............................................................................................................................................. 9
Besoins du promoteur.............................................................................................................................................. 9
Mandat du projet .................................................................................................................................................... 10
Composition de l’équipe ........................................................................................................................................ 11
Livrables et itérations ............................................................................................................................................. 12
Risques .................................................................................................................................................................... 13
Méthode de travail .................................................................................................................................................. 14 Gestion de projet ................................................................................................................................................... 14
Suivi du projet ........................................................................................................................................................ 15
Outils ...................................................................................................................................................................... 15
Présentation détaillée des technologies .............................................................................................................. 17
Spring Boot ....................................................................................................................................... 17 Vue d’ensemble ............................................................................................................................................. 17
Configuration Service .................................................................................................................................... 18
Zuul Service (Gateway) ................................................................................................................................. 18
Service Discovery (Eureka) ........................................................................................................................... 18
OAUTH2 Server ............................................................................................................................................. 19
Microservices ................................................................................................................................................. 20
ReactJS .................................................................................................................................................................... 24 Thème Jumbo React ............................................................................................................................................. 24
Structure application « front-end » ........................................................................................................................ 25
Redux..................................................................................................................................................................... 25
Composants React Utilisés ................................................................................................................................... 26
Différence entre React Redux et MVC traditionnel ............................................................................................... 26
Pages, routes et actions possibles ........................................................................................................................ 27
Base de données H2 ............................................................................................................................................... 29
Google Rest Calendar ........................................................................................................................... 30
JsPDF .................................................................................................................................................. 30
Intégration ............................................................................................................................................................... 31 Diagramme de déploiement .................................................................................................................................. 31
Intégration continue (à faire) .................................................................................................................................. 34
Problèmes rencontrés ............................................................................................................................................ 35
Ce qu’il reste à faire ................................................................................................................................................ 35
Recommandations .................................................................................................................................................. 36
Contributions de l’équipe ...................................................................................................................................... 37
Conclusion .............................................................................................................................................................. 39
Liste de références ................................................................................................................................................. 40
5
Annexe(s)
Annexe I : Prototype statique 41
Annexe II : Tableau exemple dans Trello 46
Annexe III : Exemple de commentaire dans Trello pour le suivi du temps 47
Annexe IV : Exemple de la vue des tâches archivées dans Trello 48
Annexe V : Tableau des dates/paragraphes d’un cas de cour 49
Annexe VI : Exemple de sortie PDF 50
6
Liste des tableaux
Page
Tableau I : Liste des abréviations, sigles et acronymes. 8
Tableau II : Composition de l'équipe. 11
Tableau III : Livrables du projet. 12
Tableau IV : Itérations prévues pour le projet. 12
Tableau V : Risques pour la réalisation du projet. 13
Tableau VI : Contributions de l'équipe 37
Tableau VII : Contributions des membres/Responsabilités
38
7
Liste des figures
Page
Figure I : Vue d’ensemble du tableau des tâches Trello. 14
Figure II : Vue d’ensemble de l’architecture du système Protogest. 17
Figure III : Schéma montrant les principes de OAuth2. 20
Figure IV : Diagramme de dépendances entre les couches du microservice event. 22
Figure V : Différentes couches entre les composantes d’un microservice. 22
Figure VI : Structure application Web ReactJS. 25
Figure VII : Schéma flux redux 26
Figure VIII : Schéma flux MVC Strict. 27
Figure IX : Schéma relationnel de la base de données Protogest. 29
Figure X : Diagramme de déploiement du système Protogest. 32
Figure XI : Fichier de configuration event-service pour le déploiement. 33
Figure XII : Vue d’ensemble de l’intégration continue du système Protogest. 34
8
Liste des abréviations, sigles et acronymes
Terme Définition
Protocoles d’Instances
Formulaire rempli par les avocats et les
intervenants pour s’entendre sur les dates de
déroulement de la cause.
API
Interface de programmation qui sert de façade
pour les prototypes logiciels qui l’utilisent
Spring
Framework libre pour construire et l’application
de gestion pour avocats
React
Bibliothèque JavaScript libre pour la création des
applications Web.
Document de Vision/SRS
Spécification des exigences du prototype logiciel
Service REST
Style d’architecture définissant un ensemble de
contraintes et de propriétés basées sur le
protocole HTTP.
PFE
Projet de fin d’études.
Tableau I : Liste des abréviations, sigles et acronymes
9
Objectifs
Présentation du promoteur Le promoteur du projet se nomme Frank Calendriello. Il est avocat et possède sa propre firme
d’avocats. Son entreprise se situe à Montréal.
Architecture existante Le client utilise présentement un calendrier personnel sur Outlook. La cour fournit un document nommé
protocole d’instance qui doit être rempli par un ensemble d’intervenants impliqués dans la cause. Selon
le protocole, un ensemble de dates doivent être décidées et approuvées par l’ensemble des
intervenants. Présentement, le tout est fait à l’aide de communications téléphoniques et courriels. De
plus, les différentes itérations sont généralement faites avec peu d’échange d’avis et information. Il n’y
a donc aucun logiciel en place pour appuyer cette tâche. Un exemple du protocole d’instance peut-être
retrouvé à la référence 10 de ce document.
Besoins du promoteur Le client décrit qu’il doit présentement produire le document de protocole d’instance à plusieurs reprises
jusqu’à ce qu’il soit approuvé par tous les autres intervenants/avocats. Dans le cas où une entente ne
peut pas être trouvée, le juge finit par choisir la cédule qui est meilleure à son avis. Cette décision peut
désavantager une des deux parties. Le promoteur de ce projet voudrait un logiciel qui permettant de
faciliter la communication et la négociation de dates, par Internet, évitant ainsi le va-et-vient (c.-à-d.
appels téléphoniques et courriels) lors de demandes/changements de dates. De plus, l’automatisation
pourrait peut-être augmenter les chances d’obtenir un calendrier qui plait aux deux parties plus
rapidement. Ce logiciel devrait être accessible facilement par toutes les personnes concernées. Il est
important que les informations personnelles des clients soient bien protégées. De plus, il faudrait faire
une distinction entre le créateur d’un cas et ceux qui y participent. Ainsi, seul le créateur du cas aurait
certains droits, comme le choix lors de la modification des dates afin d’accommoder les autres parties.
Les intervenants non créateurs du cas ont droit d’approuver ou refuser les dates proposées et, en cas
de refus, peuvent proposer de nouvelles dates. De plus, le promoteur souhaite que le produit permette
de faire un profit aux propriétaires du système.
10
Mandat du projet
Le mandat de l’équipe de projet de fin d’études est de produire une preuve de concept. Le prototype
résultant ne sera pas utilisé en production, mais permettra d’éclaircir et valider les fonctionnalités
requises. Le prototype logiciel prendra la forme d’un logiciel accessible sur le Web. Ses interfaces
utilisateurs seront accessibles par les participants, préalablement autorisés, ayant besoin d’interagir
avec le choix des dates des activités décrites au protocole d’instance. Les fonctionnalités visées par ce
projet sont : la création d’un calendrier commun pour un cas; l’affichage du calendrier; et la possibilité
des intervenants d’accepter ou refuser les dates proposées. Finalement, ce premier prototype devra
permettre de générer un rapport en format PDF du protocole d’instance complété pour la cour. Afin
de faciliter notre compréhension du protocole d’instance, le client nous a fourni un tableau explicatif des
dates importantes pour notre prototype dans le document ainsi que les règles d’affaires associées. Ce
document peut être trouvé en partie à l’annexe 5.
11
Composition de l’équipe
Nom Description Responsabilités
Frank Calandriello Avocat qui a eu l’idée d’informatiser le protocole d’instance et nom
Émets les besoins, valide les fonctionnalités des prototypes et donne son avis sur les résultats
Alain April Responsable de l’équipe de PFE log/ti
Responsable de l’équipe de PFE Supervise les activités de l’équipe
Simon Ethier Développeur Membre de l’équipe de conception et programmation front-end
Alexis Lemelin-Poulin Développeur Membre de l’équipe de conception, programmation front-end, chargé et contact avec le client
Anthony Corriveau Développeur Membre de l’équipe de conception et programmation front-end
Walid Bezzaoui Développeur Membre de l’équipe de conception et programmation full-stack
Tableau II : Composition de l'équipe
12
Livrables et itérations
Les tableaux suivants représentent un résumé des livrables/itérations du projet.
Nom de l’artéfact Description
Document de Vision/SRS Document exprimant les besoins et les requis du projet
Rapport final du projet Ce document présente une synthèse des activités effectuées et les résultats du projet.
Présentation du projet pour évaluation Cette présentation PowerPoint permet de synthétiser le déroulement du projet et ses résultats.
Tableau III : Livrables du projet
Itération Livrable Date de début Date de fin
1 Authentification de l’application.
Possibilité de relier des dates aux
différents évènements d’un cas.
Envoyer le choix des dates vers le
calendrier commun du cas
1er mai 2018 28 juin 2018
2 Implémentation des règles d’affaires
en lien avec les dates, ainsi que la
recherche de disponibilité dans le
calendrier de l’utilisateur.
29 juin 2018 12 juillet 2018
3 Implémentation de la réponse des
autres intervenants, leur permettant
d’accepter les dates, refuser les dates
et proposer de nouvelle date. De plus,
ajoute de l’option d’archivage des cas
quand ils sont terminés
13 juillet 2018 26 juillet 2018
Tableau IV : Itérations prévues pour le projet
13
Risques
Risque Probabilité Conséquence
Utilisation de nouvelles technologies
haut haut
Temps limité haut moyen
Tableau V : Risques pour la réalisation du projet
14
Méthode de travail
Gestion de projet
Nous avons utilisé la méthode Kanban (voir : https://en.wikipedia.org/wiki/Kanban_(development)) afin
de gérer ce projet de développement logiciel. En effet, nous avons utilisé cette méthode afin de gérer
les activités à l’aide du tableau visuel des tâches.
L’outil de gestion du projet Kanban a été Trello (https://trello.com).Nous avons créé un tableau Trello
pour l’équipe. Dans ce tableau Trello, des tâches étaient créées pour les livrables majeurs durant les
réunions d’équipe. Par la suite, les différents membres de l’équipe créaient leurs propres tâches afin de
pouvoir suivre la progression du travail ainsi que l’effort. La somme des heures effectuées est par la
suite entrée dans un tableau Google Sheets par le gestionnaire de projet à l’aide des commentaires sur
les tâches Trello archivées. Une réunion d’équipe était organisée chaque semaine afin de suivre la
progression des tâches, planifier le travail de la semaine suivante ainsi que de discuter des bloquants.
Par la suite, les différents membres de l’équipe s’assignaient des tâches à faire pour la semaine à venir.
Chaque semaine, la progression des livrables était présentée devant les autres membres de l’équipe
lors de la réunion hebdomadaire. La progression des versions du code était enregistrée et gérée à
l’aide de Github. La partie « back-end » du produit était enregistrée sur un dépôt Git public, alors que la
partie « front-end » était sur un dépôt privé pour des raisons de licence du produit utilisé. En effet,
l’utilisation d’un système payant pour le développement de l’interface Web du produit nous impose de
ne pas partager publiquement ce code source.
Figure I : Vue d’ensemble du tableau des tâches Trello.
15
Suivi du projet
Le projet a débuté par une analyse des besoins et le développement d’une proposition de projet
avec le promoteur et le superviseur du projet. Chaque semaine, nous avions des réunions d’équipe
afin de suivre l’avancement du projet et de voir où le projet était rendu. Durant ces réunions, dites
agiles, les différents membres de l’équipe s’associaient des tâches. De plus, une démonstration du
projet était faite au superviseur de notre projet de manière hebdomadaire. Finalement, le projet s’est
conclu par la rédaction du présent rapport final et la production d’une présentation académique du
projet de fin d’études.
Outils
● GitHub
○ Le github du « front-end » est accessible à l’adresse : https://github.com/walidbe/protogest-react
○ Le github du « back-end » est accessible à l’adresse : https://github.com/walidbe/protogest
● Trello
Ce logiciel libre sert à faire de la gestion de projet, de style Kanban. En effet, l’interface
permet la simulation d’un tableau de « Post-it ». Les fonctionnalités de base sont gratuites,
et nous nous sommes restreints à cette utilisation. Notre tableau Trello nous a permis de
suivre plusieurs informations pertinentes sur le projet. Premièrement, nous avons séparé le
tableau en quatre colonnes, “à faire”, “en cours”, “terminée” et “hebdomadaire”. Les trois
premières représentés l’état des tâches alors que la dernière sert au suivi des activités
répétitives, tel que les rencontres. Un tableau d’exemple a été produit pour la représentation
du tableau de base, à l’annexe 2. Les tâches étaient créées et attitrées à un ou plusieurs
membres de l’équipe lors des réunions. Elles commençaient dans la colonne “à faire”. Une
fois un effort effectué sur la tâche, le responsable de la tâche la place dans la section “en
cours. Après avoir investi du temps dans une tâche, la personne doit y ajouter un
commentaire comprenant la semaine de travail ainsi que le nombre d’heures, sous le format
: “semaine X : Y heures”. Un exemple est présent à l’annexe 3. Une fois la tâche considérée
terminée, elle passe à la colonne “terminée”. Elle y restera jusqu’à la prochaine réunion
d’équipe. À ce moment, un retour sera fait sur l’ensemble des tâches qui seront archivées
en cas de complétion, ou retourné dans la section “à faire” si des ajustements doivent être
faits. Une fois la tâche archivée, le temps est ajouté à la Google Sheet qui garde les
16
informations en lien avec le temps de travail. Un code de couleur a aussi été utilisé pour
ajouter de l’information aux tâches, telles que l’importanceou un état d’attente. Une prise
d’écran exemple de nos tâches archivées peut être trouvée à l’annexe 4.
● Google Docs
L’éditeur de texte gratuit de Google. La fonctionnalité intéressante de ce produit est la capacité,
pour tous les membres, de travailler sur un document en même temps. De plus, le partage de
droit sur un document est pratique pour le partage d’information. Nous avons utilisé cet outil pour
la création et le partage de l’ensemble des documents pour ce projet.
● Google Sheets
Comme Google Docs, Google Sheets est un produit gratuit qui permet un partage facile des
documents produit. Par contre, celui-ci produit des tableaux et feuilles de calcul. Dans le cadre
du projet, nous avons utilisé un tableau du genre pour faire les calculs en lien avec le temps de
travail des membres de l’équipe. Le tableau peut-être retrouvé en Annexe et au lien suivant
https://drive.google.com/drive/u/2/folders/1F7UhpO5JQXTQr8FuuNWbfR5Ec86VrCiy
● Lucid Charts
Lucid Charts est un logiciel permettant de faire divers diagrammes facilement et rapidement. Cet
outil permet autant de faire des diagrammes UML que des schémas de bases de données. Il
nous a permis de faire tous les diagrammes présents dans notre document de vision/SRS ainsi
que ceux de notre rapport technique.
17
Présentation détaillée des technologies
Spring Boot
Vue d’ensemble
La figure suivante présente une vue d’ensemble de l’architecture du système Protogest :
Figure II : Vue d’ensemble de l’architecture du système Protogest.
18
Configuration Service
Nous utilisons Spring Cloud Configuration qui est en effet un service de configuration de nos
microservices. Ce module est en effet extensible horizontalement pour notre système distribué.
En fait, nous utilisons actuellement 1 seul type de profil soit celui du développement qui est pour le
moment en stockage local pour chaque microservice. Idéalement, il faudrait partager le dossier config-
repository en créant tous les fichiers de configuration pour chaque microservice à l’intérieur de ce
dossier, et finalement utiliser une couche de référentiel qui prend en charge le stockage Git.
L’utilisation d’un dossier partagé contenant toutes les configurations selon plusieurs profils soit (dev,
prod) va faciliter l’accès des microservices à leur configuration selon le profil activé.
Zuul Service (Gateway)
Le but de l’utilisation d’un « gateway » est pour avoir un point d’entrée unique dans le système, soit la
seule entité exposée à l’extérieur pour le client est Zuul-Service. Son utilisation consiste à traiter les
demandes du client et rediriger les requêtes vers le microservice approprié. L’utilisation du Gateway est
non seulement pour la redirection, mais peut aussi être utilisée pour la sécurité, la gestion du trafic, etc.
Une solution alternative à cela sera d’appeler directement les microservices, mais cette solution est
facilement très limité étant donné qu’il faudrait connaître le port et l’adresse de chaque microservice,
cela devient vite un goulot d’étranglement vu que le système est extensible horizontalement, sans
oublier que les microservices deviennent vulnérables aux entités extérieures.
Service Discovery (Eureka)
Eureka permet en général la découverte des autres microservices. En effet, il s’agit de la détection
automatique des emplacements réseau des instances de chaque microservice, exemple : user- service,
« event-service », etc. Ces derniers doivent s’enregistrer au « Service Registry » et ce pour chaque
microservice puisse communiquer avec un autre. Cet attribut est très commun dans les systèmes
19
distribués où l’infrastructure est hétérogène et donc les communications se font par un « middleware
» pour que tous les systèmes puissent se comprendre.
OAUTH2 Server
Nous utilisons « OAuth2 » pour la gestion de « token » et des ressources. Notre serveur
d’autorisation est utilisé pour l’autorisation de l’utilisation à accéder au système en plus de la
sécurisation de chaque fonction de nos microservices.
Spring Cloud Security fournit des annotations pour faciliter l’implémentation du serveur d’autorisation.
En effet, lorsque l’utilisateur envoie son courriel et son mot de passe dans une session X, le serveur
d’autorisation qui génère le « token » appelé pour valider les informations de l’utilisateur. Une fois validé,
un « token » sera généré et retourné à la session de l’utilisateur. Ce « token » est très important, car il
sera utilisé pour accéder aux fonctions de chaque microservice, étant donné qu’il contient le type de
l’utilisateur ainsi que ses autres informations, tells que: le nom, prénom, etc.
Idéalement, selon les bonnes pratiques, il devrait y avoir trois points de validation lors de l’autentification:
● Auth Server : ce serveur s’occupe de générer le « token » de l’utilisateur;
● Validate Server : ce serveur s’occupe de valider le « token » de l’utilisateur;
● Info Server : ce serveur s’occupe de retourner les informations de l’utilisateur selon le «
token » validé.
La partie client est assez facile à gérer étant donné que le « token » est généré. Il est possible
soit de l’enregistrer dans une session ou dans un « Cookie ».
20
Figure III : Schéma montrant les principes de OAuth2.
Microservices
Event-Service: Ce service gère la création des évènements, l’affichage, la modification ainsi que la
gestion de conflit des évènements avec le calendrier de l’utilisateur. Une architecture plus détaillée sera
expliquée dans les paragraphes et sections suivantes.
Chaque microservice bénéficie d’une architecture en couche entre ses composantes. En effet, nous
utilisons des patrons communs pour chaque application, conséquemment chaque service contient
minimalement 5 couches : 1) Configuration; 2) Controller; 3) Service; 4) Mapper; et 5) Repository:
Configuration : parmi les avantages de l’utilisation de la technologie Spring Boot, sa facilité de
configuration des dépendances est très intéressante. En effet, Spring fonctionne par la nomination des
objets gérés par l’injection des dépendances, soit avec des annotations qui permettent de définir un
élément. Par exemple, l’annotation « @Configuration » permet de marquer la classe comme une
source de définitions des « beans » pour le contexte de notre application. En fait, un « bean » est un
objet qui est géré par la technique IOC (Inversion Of Control) qui s’occupe d’initialiser et d’assembler
cet objet. Finalement ils sont représentés dans les métadonnées de configuration qui peuvent être
exprimées en annotations.
21
Admettons par exemple nous voulons instancier l’objet « EventService » pendant la configuration, nous
allons donc créer une méthode qui sera annotée par le mot clé « @Bean » et qui retourne la référence
de l’objet « eventService » qui vient d’être initialize. Cette valeur de retour sera enregistrée en tant que
« bean » dans une « BeanFactory » et pourra être utilisée plus tard dans l’application en utilisant
l’annotation « @Autowired ».
Controller : cette couche permet, en général, de récupérer les requêtes envoyées par le client et
les rediriger vers la couche de service.
Service : Cette couche fait le traitement des requêtes reçues et retourne le résultat au contrôleur.
Mapper : Les objets reçus par la base de données peuvent être lourds, car ils contiennent des
références sur d’autres objets et ainsi de suite. Pour régler ce problème, nous avons décidé de créer
des objets de type DTO (Data Transfer Object) qui seront retournés comme résultat au client.
Idéalement, chaque mapper, de chaque service, doit contenir minimalement deux fonctions: 1) la
fonction pour convertir un objet DAO à un objet DTO; et 2) une autre fonction pour convertir un objet
DTO à un objet DAO. Cette dernière fonction (c.-à-d. la deuxième) sera appelée lorsque nous voulons
sauvegarder un objet dans la base de données. Cette approche qui consiste à faire le « mapping »
manuellement n’est pas la meilleure, car il existe des librairies qui peuvent effectuer ce travail, comme
« ModelMapper » qui semble une librairie assez solide et efficace. Il est donc recommandé de l’utiliser
dans les prochaines itérations du prototype.
Repository: Cette couche contient des interfaces qui héritent de « CrudRepository ». En effet, Spring
utilise « JPA » pour accéder et stocker les données dans la base de données. Sa caractéristique la plus
intéressante est la possibilité de créer des implémentations de référentiel. Cette technique facilite
beaucoup la gestion des requêtes SQL. Par exemple, si nous avons besoin d’une requête pour lire le
nom de l’utilisateur, au lieu de faire la requête typique SQL (c.-à-d. SELECT nom from utilisateur).
Nous pouvons créer une interface qui hérite de « CrudRepository<Utilisateur, Object> », et nous
pouvons créer la signature de la fonction qui va remplacer la requête traditionnelle. Par exemple, «
findAll() ».
22
Figure IV : Diagramme de dépendances entre les couches du microservice event.
Figure V : Différentes couches entre les composantes d’un microservice.
Member-Service (c.-à-d. User-service) : Ce service gère l’authentification, la création, ainsi que la
gestion sécurisée du « token » pour l’utilisateur. Nous utilisons ce service pour récupérer les
informations de la personne authentifiée et toutes autres tâches reliées au profil de l’utilisateur.
Task-Service : Ce service gère l’affichage des sections du protocole de l’instance.
Report-Service: Ce service gère la génération des rapports selon les évènements créés.
23
Email-Service : Comme son nom l’indique, ce microservice s’occupe de la gestion de courriel, soit
l’envoi des notifications aux utilisateurs.
Calendar-Service : Ce microservice utilise le « token » de l’utilisateur pour se connecter à son
calendrier personnel et gérer les évènements de ce dernier.
Vote-Service : Ce microservice n’a pas été utilisé, mais il doit gérer les votes des utilisateurs
concernant les dates des évènements en question.
24
ReactJS
ReactJS est une bibliothèque JavaScript afin de faciliter la création d’applications Web monopage (c.-
à-d. Single Page Application). Nous utilisons actuellement un gabarit configurable pour bâtir notre
prototype d’application. L’architecture de notre prototype d’application Web est basée sur des
composants qui vont former un « DOM » au rendu de l’application et qui peuvent être intégrés et
réutilisés sur notre plateforme.
Thème Jumbo React
Pour la réalisation du prototype fonctionnel, nous avons choisi de prendre le thème Jumbo React. Ce
thème nous a permis de développer rapidement un prototype d’application Web grâce à ses
composants déjà intégrés et sa librairie de « Material-UI » fournit le « package ».
Nous avons utilisé plusieurs composants de la librairie « Material-UI » :
● Boutons;
● Listes;
● TextField;
● CardBox;
● DialogBox;
● Avatar;
● Chips.
Grâce à ces éléments disponibles, il nous a été possible d’avoir une belle interface graphique sans trop
d’effort. Aussi, la structure du thème est bonne et il est facile de se retrouver à travers les différents
dossiers et fichiers du thème. En effet, avec React les fichiers sont regroupés par routes.
Un autre avantage de l’utilisation de Jumbo React, est que ce thème est multilingue, mais pour nos
besoins nous avons seulement utilisé le français et l’anglais. Aussi, Jumbo React est « responsive »
(c.-à-d. qu’il s’affiche bien sur toutes les plateformes populaires), donc il s’adapte autant à un écran
d’ordinateur de bureau, une tablette ou encore un mobile.
Liens utiles :
● Démo : http://demo.g-axon.com/jumbo-react/#/app/dashboard/default
● Documentation : http://jumbo-react.g-axon.com/docs/material/
● Achat fait sur : https://themeforest.net/item/react-material-bootstrap-4-admin-
template/20978545
25
Structure application « front-end »
La structure de notre application Web utilisant React se décompose en petits blocs pour chacun des
modules de l’application, comme le démontre le schéma suivant :
Figure VI : Structure application Web ReactJS.
Redux
Redux est l’une des implémentations les plus importantes pour faire une gestion centralisée de notre
application Web. En gros, Redux est nécessaire pour gérer l’état global entre les composants. Par
exemple, un évènement utilisateur va déclencher une action. Cette dernière va mettre à jour l’état global
de notre application pour ensuite mettre à jour l’interface utilisateur. Avec Redux, on ajoute en effet la
notion de store. Ce dernier est toujours global. Il contient donc toutes les informations de tous les
composants de l’application.
Pour une meilleure compréhension, voici un résumé du flux Redux :
● Store : Le store contient l’état global de l’application. En effet, il contient les références
immuables de l’état des composants et ne peuvent être modifiées qu’en appelant les
26
actions.
● Action : Les actions contiennent tout simplement les informations à envoyer au Store, c’est l’équivalent d’un contrôleur dans une architecture MVC.
● Reducers : Les « reducers » s’occupent de récupérer les actions et tout simplement mettre à
jour le Store. Voici un schéma montre le processus d’un flux Redux :
Figure VII : Schéma flux Redux
Composants React Utilisés
Nous avons utilisé des composants React pour faciliter le contrôle des données et pour l’affichage de
nos éléments visuels:
● Big-Calendar : S’occupe d’afficher un calendrier à partir des données reçues;
● Axios : Gestion des appels REST vers le gateway du back-end pour ensuite récupérer les
données;
● Moment : Utilisé pour la gestion des dates;
● jsPDF : Utilisé pour générer un document PDF.
Différence entre React Redux et MVC traditionnel
Pour commencer, pour faire du React, il faut complètement changer la manière de penser, car on est
loin d’une approche avec parton MVC traditionnel. Premièrement, React a des règles très strictes quant
à ses règles de « flow » alors que MVC n’est pas vraiment renforcée par des règles. Deuxièmement, la
27
direction du « flow » n’est pas pareil, avec React, le « flow » est unidirectionnel alors qu’en MVC le
flow peut-être souvent bidirectionnel. Troisièmement, React utilise un « store » central qui contient tous
les états des éléments React alors qu’en MVC, c’est normalement les objets qui possèdent leurs propres
états et non l’application centrale. Pour terminer, React Redux est avantageux, car nous changeons
l’état par des actions qui sont des objets JavaScript purs. Cela signifie que nous pouvons à tout moment
recréer l’état à partir de zéro si nous conservons un journal des actions. En effet, la journalisation des
évènements nous permet de savoir qui modifie l’état et quand exactement. D’autre part, le débogage
est facile avec React, car en enregistrant toutes les actions, nous pouvons recréer l’état entier.
Figure VIII : Schéma flux MVC Strict.
Pages, routes et actions possibles
Page : Création de compte
Route : /signup
Action(s) possible(s) : Possibilité de créer un compte avec une adresse courriel.
Autorisation : Aucune
Page : Connexion
Route : /signin
Action(s) possible(s) : Connexion à l’application (porte d’entrée) avec un compte préalablement
créé.
Autorisation : Aucune
Page : Create A Case
Route : /create
28
Action(s) possible(s) : Dans cette page, on peut créer un cas à l’aide du formulaire. On peut aussi
ajouter des intervenants avec leur adresse courriel. Une logique de date est implémentée pour ne pas
qu’une date arrivée une fin de semaine.
Autorisation : Il faut avoir une autorisation spéciale pour faire la création de cas.
Page : Events (Page d’accueil par défaut)
Route : /events
Action(s) possible(s) : Dans cette page, un créateur de cas peut voir l’avancement sur les
approbations des dates d’un cas et les propositions des différents intervenants s’ils ont proposé de
nouvelles dates. Il est aussi possible de filtrer les cas et de faire une recherche.
Autorisation : Il faut avoir une autorisation spéciale pour faire la gestion des dates des cas.
Page : My Requests
Route : /requests
Action(s) possible(s) : Dans cette page, un intervenant peut approuver une date pour un évènement
d’un cas ou encore il peut proposer deux nouvelles dates pour cet évènement. Il est aussi possible de
faire une recherche à travers les demandes de dates.
Autorisation : Aucune
Page : List of Cases
Route : /calendar
Action(s) possible(s) : Dans cette page, il est possible de voir les dates d’un cas dans un calendrier.
Il est possible d’exporter les dates vers un PDF.
Autorisation : Aucune
29
Base de données H2
Pour faciliter l’accès aux données et leurs configurations pour le développement, nous avons décidé
d’utiliser la technologie H2 (http://www.h2database.com/html/main.html). Les requêtes SQL sont
semblables à celles de MySQL. De plus, les tables de H2 peuvent être créées en mémoire vive ce qui
améliore considérablement la performance d’accès aux données. Pour un déploiement en production,
il serait mieux d’utiliser une base de données MySQL.
La figure suivante démontre le schéma relationnel de notre base de données :
Figure IX : Schéma relationnel de la base de données Protogest.
30
Hibernate/JPA
Pour gérer la persistance des objets dans notre base de données relationnelle, nous utilisons
Hibernate/JPA qui nous permet d’accéder et de sauvegarder rapidement un objet java dans la base de
données. En effet, JPA et Hibernate permettent d’éviter l’écriture de requêtes SQL. Hibernate va donc
se charger de faire la correspondance entre les objets et la table correspondante dans la base de
données.
Google Rest Calendar
Notre prototype d’application utilise les services Rest de Google Calendar pour se connecter et accéder
au calendrier de l’utilisateur. Ce microservice s’occupe de gérer le calendrier « calendar-service ».
Cependant, ce microservice ne donne pas la permission à l’application d’obtenir les autorisations
nécessaires pour se connecter au calendrier de l’utilisateur. Ceci est en effet un petit problème de
gestion d’autorisation de l’application. Une solution temporaire pour donner l’autorisation à votre compte
Google est de rouler le service « SpringGmailCalendarAPI » que vous pouvez trouver dans le répertoire
suivant : https://github.com/walidbe/SpringGmailCalendarAPI.
Idéalement, l’autorisation doit être implémentée dans « calendar-service ».
JsPDF
Pour faire la génération des documents PDF du protocole d’instance, nous avons utilisé la libraire libre
« jsPDF ». Cette librairie est très simple à utiliser et permet facilement de générer des documents PDF
modifiables et personnalisables. Il suffit de déclarer une nouvelle variable JavaScript. Par la suite, il
suffit de choisir la police et le différent style à appliquer au texte. Par la suite, il suffit d’ajouter le texte
dans l’objet PDF. Finalement, on génère l’objet PDF à l’aide d’une autre instruction JavaScript.
31
Intégration
Diagramme de déploiement
Déployer un système utilisant une architecture distribuée est souvent plus difficile que de déployer une
application ayant une architecture monolithique. En effet, les microservices de notre système sont
complètement indépendants les uns des autres, il est donc nécessaire d’avoir une compréhension du
fonctionnement de ces derniers.
Le diagramme de déploiement présenté ci-dessous est composé en plusieurs parties :
Microservices : nos applications indépendantes seront empaquetées dans des conteneurs en utilisant
« Docker ». En fait, il existe plusieurs avantages d’utiliser « Docker », car c’est logiciel libre, mais aussi
il permet l’isolation des applications, ce qui est très utile pour effectuer des tests sans faire planter le
serveur de production client. Nous estimons donc que ces images « Docker » doivent être hébergées
dans PCF, ce dernier offre beaucoup davantage pour l’hébergement des systèmes distribués soit par
sa variété de technologie compatible, mais mieux, car c’est un service qui est spécifiquement offert aux
applications Spring-Boot, donc nous pouvons profiter de certains outils déjà prêts à utiliser sur PCF
comme le « service-registry » et le service de configuration.
D’une autre part, nous pensons utiliser la base de données MySQL en production, soit en utilisant un
service de stockage de données en ligne offert par PCF qui est un service extensible et facile à
configurer.
Étant donné que nous utilisons un « gateway » pour la redirection de nos requêtes. Notre application
ReactJS communiquera seulement avec notre service « Zuul-service » en utilisant un protocole « https
».
Étant donné que ReactJS crée des applications monopage (c.à-d. Single Page Application), nous
pouvons utiliser un fichier JavaScript qui contient la totalité des composantes de l’application, la même
chose que pour nos microservices « back-end », PCF offre des services pour les applications ReactJS,
ainsi qu’une variété d’application côté client, par exemple: AngularJS. Nous pensons donc encapsuler
cela dans un service PCF.
La figure suivante présente un diagramme de déploiement du système Protogest :
32
Figure X : Diagramme de déploiement du système Protogest.
Configuration
Pour déployer nos microservices sur PCF, il faut créer un fichier de configuration pour chaque
application qui contient les informations concernant le service ainsi qu’aux autres services nécessaires
pour le fonctionnement de notre application.
Par exemple, « event-service » est un micro-service qui nécessite la communication avec le service «
Eureka » soit le « registry-service » pour s’enregistrer et pouvoir communiquer avec les autres
applications infonuagiques, ainsi que d’autre service comme « config-service ». « Event-service » a
aussi besoin du lien de la base de données, heureusement nous n’avons pas besoin de spécifier le lien
au complet de la base
33
de données, car cette dernière se trouve aussi sur PCF, il est juste nécessaire de spécifier le nom de
chaque service que nous voulons lier à notre microservice.
Voici un exemple d’utilisation d’un fichier de configuration yaml pour le déploiement du service « event
» sur PCF :
Figure XI : Fichier de configuration « event-service » pour le déploiement.
Le fichier de configuration indiqué ci-dessus permet au service « event-service » d’obtenir un nom de
domaine « event-cloud-service », il est ainsi connecté à d’autres services qui doivent être créés via PCF
contenant les noms : «
● registry-service ».
● « config-service ».
● « mysql-service ».
Finalement, il faut spécifier quel type d’environnement vous utilisez pour le déploiement de votre
application soit le développement ou la production.
34
Intégration continue (à faire)
L’utilisation d’un outil d’intégration pour avoir une infrastructure du système complètement automatisée
ou avec d’autres termes la livraison continue nous permet de toujours disposer d’un artéfact prêt au
déploiement. Travis est un outil d’intégration continue qui nous permettra d’automatiser les tests, ainsi
que chaque modification du code sera testée, analysée ensuite déployée.
Dans la figure suivante, après avoir poussé du code sur GitHub, un déclenchement d’évènement par «
Travis » va permettre de rouler tous les tests unitaires ainsi que de rouler un outil d’analyse de code
comme « Static analysis tools ». Finalement, si le tout est correct, « Travis » va marquer des images
pour chaque microservice réussi, pour chaque image « Docker», elle sera déployée sur PCF soit en
production ou en développement.
La figure suivante présente un diagramme d’intégration continue du système Protogest :
Figure XII : Vue d’ensemble de l’intégration continue du système Protogest.
35
Problèmes rencontrés
Lors de ce projet de fin d’études, l’un de nos plus grands défis fut d’apprendre ReactJS. En effet, c’était
une nouvelle technologie pour tous les membres de notre équipe (sauf Walid). Nous avons donc dû
investir beaucoup de temps afin d’apprendre comment fonctionne ReactJS. Cela a pris beaucoup
d’effort, car en plus d’apprendre un nouveau langage de programmation, nous avons eu à apprendre
une nouvelle façon de concevoir et programmer. En effet, React ne fonctionne pas selon un modèle
MVC standard. Il introduit un nouveau paradigme avec les notions de store et de composants. Nous
avons donc eu à nous familiariser avec ce nouveau paradigme.
De plus, nous avons aussi eu quelques problèmes avec les services Rest de Google Calendar. En effet,
notre application utilise les services Rest de Google Calendar, pour se connecter et accéder au
calendrier de l’utilisateur. Le microservice « calendar-service » ne donnait pas la permission à
l’application d’obtenir les autorisations nécessaires pour se connecter au calendrier de l’utilisateur. Nous
avons donc eu à développer une solution temporaire afin de pouvoir obtenir ces autorisations. Cette
solution est de rouler le service « SpringGmailCalendarAPI ». On peut le trouver au lien suivant :
https://github.com/walidbe/SpringGmailCalendarAPI.
Ce qu’il reste à faire
Il reste quelques tâches à compléter afin de pouvoir dire que le premier prototype soit complet. En effet,
il reste à implémenter la logique d’affaire pour les différentes dates et évènement d’un cas. En effet,
certains évènements du protocole d’instance des avocats doivent nécessairement avoir lieu dans un
certain délai après les évènements précédents. Il reste à implémenter ces restrictions dans notre
système afin que ces délais soient respectés. Une liste des évènements et des délais est disponible en
annexe ainsi que dans le dossier Google Drive de l’équipe. Pour l’instant, nous n’affichons pas tous les
évènements dans notre prototype.
36
De plus, il nous reste aussi à générer les documents officiels que les différents avocats pourraient
soumettre à la cour afin de pouvoir faire avancer une cause devant les tribunaux. En effet, pour l’instant,
nous faisons seulement générer un document PDF générique à notre système. Ce document ne contient
que les noms des différents évènements d’un cas ainsi que les dates associées à ceux-ci. Dans le futur,
il faudrait améliorer cette fonctionnalité afin qu’elle puisse produire le document officiel avec les bonnes
dates aux bons endroits. Par la suite, il resterait seulement à envoyer le document à la cour. Une option
pour envoyer ce document automatiquement pourrait être implémentée dans le futur.
Il reste également à faire le déploiement de notre prototype comme nous l’avons mentionné dans les
sections précédentes. Nous ne l’avons pas fait par manque de temps. De plus, cela était aussi peu
prioritaire dans le cas de la réalisation d’un prototype.
Il reste aussi à continuer de travailler sur différents services afin de les peaufiner et de bien les faire
fonctionner. En effet, par exemple, vote-service n’a pas été utilisé, mais il devrait gérer les votes des
utilisateurs concernant les dates des évènements en question. Il faudrait continuer à le développer afin
de mieux faire la gestion des votes des différents avocats.
Il faudrait aussi faire un mode d’administration de l’application afin de pouvoir modifier des délais de
certains protocoles d’instances ainsi que de pouvoir donner le privilège à certains usagers de créer des
cas. Par contre, ce n’est qu’une suggestion afin de rendre le prototype plus vivant.
Recommandations
ModelMapper Dans le système actuel, nous procédons d’une façon manuelle pour convertir les classes DTO à des
classes DAO et vice-versa, il s’agit en effet de la création de deux fonctions principales pour chaque
modèle qui permettent de faire l’implémentation de ce principe. Cette solution n’est pas efficace à long
terme, mais aussi c’est un travail supplémentaire pour le programmeur, car il existe des librairies qui
permettent d’effectuer cette conversion. En fait, modelmapper est une librairie disponible sur JAVA qui
permet de convertir nos classes à une version plus légère soit DTO.
Pour prendre connaissance de la librairie et de ses fonctionnalités, merci de voir le lien suivant :
https://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application
37
MySQL Comme expliqué auparavant, pour le développement local, nous utilisons la base de données H2 pour le
stockage de nos données. Pour un déploiement, nous devons utiliser MySQL, il n’existe en effet aucune
configuration supplémentaire à faire étant donné que nous utilisons Hibernate/JPA pour une meilleure
portabilité.
Gestion d’autorisation L’accès au calendrier personnel de l’utilisateur nécessite une autorisation de deux tiers. D’une part,
l’utilisateur doit accorder les droits à l’application d’utiliser les services REST, d’une autre part, l’application
doit être autorisée par les services de Google pour avoir le privilège d’accès au calendrier personnel. Ce
deuxième point est en effet problématique, car le prototype actuel ne permet pas cela, il existe une solution
temporaire pour parvenir à régler ce problème qui est disponible dans le répertoire suivant :
https://github.com/walidbe/SpringGmailCalendarAPI
Contributions de l’équipe
Pour la réalisation du projet de fin d’études, chaque membre à contribuer au travail.
Membre Heures consacrées Commit GIT Front-end Commit GIT Back-end
Walid 156 heures 24 76
Anthony 80 heures 24 0
Simon 80 heures 3 0
Alexis 70 heures 0 0
Tableau VI : Contributions des membres
** NB : Souvent les commits se sont faits en équipe de deux.
38
Membre de l’équipe Responsabilité
Walid • Programmation du Back-End
• Programmation des micros-services
• Programmation de la gestion d’un cas et
de ses évènements
• Rencontre avec le client
Anthony • Programmation du Front-End
• Programmation de la gestion du calendrier
d’un cas et ses évènements
• Gestion des composants Jumbo React
• Affichage des cas dans le menu
• Génération du prototype statique
Simon • Programmation du Front-End
• Programmation de la gestion du calendrier
d’un cas et ses évènements
• Génération des documents PDF
Alexis • Programmation du Front-End
• Programmation de la gestion du calendrier
d’un cas et ses évènements
• Assurance qualité
• Gestion de projet
• Rencontre avec le client
• Génération du prototype statique
Tableau VII : Contributions des membres/Responsabilités
39
Conclusion
Ce projet de fin d’études avait pour mandat de concevoir un prototype logiciel qui permet à des avocats
de différentes firmes de s’entendre sur les dates des différentes étapes d’un cas avant d’aller à la cour
(c.-à-d. de remplir le protocole d’instance). L’objectif est de raccourcir le temps et de diminuer l’effort
nécessaire à coordonner les intervenants et ainsi améliorer le fonctionnement du système de justice
québécois. Bien qu’il y ait beaucoup de temps consacré à la formation, dans le cadre de ce projet, ce
fut un investissement nécessaire puisque certains membres de l’équipe n’avait pas d’expérience avec
la technologie ReactJS au préalable. Nous avons pu apprendre une nouvelle technologie émergente
qui nous a permis de développer nos compétences. Finalement, l’équipe a réussi à produire un premier
prototype. Cette première version du prototype n’est pas complète, cependant, elle fournit une
excellente base de départ qui sera utile pour les équipes qui continueront à le développer et à le
peaufiner à l’avenir.
40
Liste de références
1) jsPDF. 2018. jsPDF - HTML5 PDF Generator | Parallax. Repéré à
https://parall.ax/products/jspdf
2) MrRio. 2010.Client-side JavaScript PDF generation for everyone.
Repéré à https://github.com/MrRio/jsPDF
3) Levkovsky, Mikhali. 2017. Thinking in Redux (when all you’ve known is MVC). Repéré à
https://hackernoon.com/thinking-in-redux-when-all-youve-known-is-mvc-c78a74d35133
4) Zaouali,Aymen. 2018. Pourquoi utiliser ReactJs. Repéré à
https://medium.com/@aymenzaouali/pourquoi-utiliser-react-js-88731b3cafe6
5) Jumbo. 2018. React Material Version. Repéré à http://jumbo-react.g-axon.com/
6) Jumbo. 2018. Jumbo React - Docs. Repéré à http://jumbo-react.g-axon.com/docs/material/
7) Jumbo. 2018. Jumbo React - Admin Dashboard. Repéré à http://jumbo-react.g-
axon.com/docs/material/
8) Mkyong.2017. Spring Boot Tutorials - mkyong.com. Repéré à
http://www.mkyong.com/tutorials/spring-boot-tutorials/
9) Spring. 2018. GETTING STARTED - Building an Application with Spring Boot, Repéré à
https://spring.io/guides/gs/spring-boot/
10) Google. 2018. Documentation Protogest. Repéré à
https://drive.google.com/drive/u/2/folders/1F7UhpO5JQXTQr8FuuNWbfR5Ec86VrCiy
41
ANNEXE I
PROTOTYPE STATIQUE
Écran : Page de connexion
42
Écran : Page Accueil
43
Écran : Page d’un cas
44
Écran : Page création d’un cas (pop-up)
Écran : Page d’acceptation du défendeur
45
Écran : En cas de refus (défendeur)
46
ANNEXE II
TABLEAU EXEMPLE DANS TRELLO
47
ANNEXE III
EXEMPLE DE COMMENTAIRE DANS TRELLO POUR LE SUIVI DU TEMPS
48
ANNEXE IV
EXEMPLE DE LA VUE DES TÂCHES ARCHIVÉES DANS TRELLO
49
ANNEXE V
TABLEAU DES DATES/PARAGRAPHES D’UN CAS DE COUR
50
ANNEXE VI
EXEMPLE DE SORTIE PDF
