SlideShare une entreprise Scribd logo
1  sur  83
Télécharger pour lire hors ligne
République Tunisienne
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université de Tunis El Manar
École Nationale d’Ingénieurs de Tunis
DÉPARTEMENT TIC
Projet de fin d’études
Présenté par
Mohamed BOUBAYA
Pour l’obtention du
Diplôme National d’Ingénieur en Télécommunications
Refonte et déploiement des modules en
utilisant l’architecture micro-services
Réalisé à
Soutenu le 26/09/2018
Devant le Jury :
Président : M. Taoufik AGUILI
Rapporteur : Mme
Monia TURKI
Encadrant Organisme d’accueil : M. Guillaume BADIN
Encadrant ENIT : M. Taher EZZEDINE
Année universitaire 2017/2018
Signatures
Superviseur Silk : M. Guillaume BADIN
Superviseur ENIT : M. Tahar EZZEDINE
i
Dédicace
À mes chers parents qu’aucune mot ne pourrais exprimer ma gratitude et mon amour,
que ce travail soit le couronnement de votre implication, vos efforts, vos sacrifices et votre
dévouement absolu.
À mon frère et mes soeurs, que le bonheur, la réussite et la prospérité bénissent vos
chemins.
Aux membres de ma famille, pour vos encouragements continu votre soutien.
À mes amis pour votre orientation, votre affection et votre présence.
À toute personne qui a croisé mon chemin.
Je tiens à vous dédier cet travail.
ii
Remerciements
Au terme de ce travail, J’ai un plaisir de réserver ces quelques lignes de gratitude à
tous ceux et celles qui, de près ou de loin, ont contribué à la réalisation et l’aboutissement
de ce travail.
Mes remerciements s’adressent particulièrement à :
• M. Christophe DUBERNET DE BOSCQ, directeur Général de Silk, pour m’avoir
prodigué l’honneur de travailler dans son équipe.
• M. Guillaume BADIN, chief projet et mon encadrant de stage qui a proposé et suivi
ce travail. Je lui exprime toute ma profonde de reconnaissance pour la confiance
et son aide qu’il m’a apporté long toutes les phases de ce stage. Ses conseils, sa
disponibilité, son encadrement et m’ont été précieux qu’il m’a prodigués autant
pour atteindre les objectifs.
• M. Taher EZZEDINE, maître de conférences à l’École Nationale d’Ingénieurs de
Tunis, pour son soutien et sa rigueur pour la qualité de son enseignement et ses
conseils sans oublier sa participation au cheminement de ce rapport.
• A mes amis à Silk et spécialement Rémi KOWALSKI, Florian GALLE, Lounès
BADJI, Hubert RAYNAUD et Benjamin BONNETTO pour leur aide et leurs pro-
positions long de ce stage.
• Mon dernier mot s’adresse à tous les membres de l’honorable jury que je remercie
d’avoir accepté d’examiner ce modeste travail.
iii
Résumé
Projet s’inscrit dans le cadre d’un projet de fin d’études au sein de l’entreprise Silk
France pour une durée de six mois. Dans un environnement Agile, la société m’a confié la
mission de développer des plusieurs modules : un module pour la gestion du laboratoire
un autre pour la gestion du personnel de laboratoire et un module POC permet d’envoyer
des messages instantanés en temps réel, réagir à un message et partager des fichiers.
Mots clés : Scala, Play2.6, RabbitMQ,API REST, API WebSocket.
Abstract
Project is part of a graduation project within the company Silk France for a period
of six months. In an Agile environment, the company entrusted me with the mission of
developing several modules : a module for the management of the laboratory another for
the management of the laboratory staff and a POC module makes it possible to send
instant messages in real time, react to a message and share files.
Key Words : Scala, Play2.6, RabbitMQ,API REST, API WebSocket.
iv
Table des matières
Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Liste des tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Liste des acronymes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Introduction Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Cadre du projet 2
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 3
1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Avantages de la méthode agile Scrum . . . . . . . . . . . . . . . . 5
1.4.2 Environnements mis en place . . . . . . . . . . . . . . . . . . . . . 5
1.4.3 L’ensemble des acteurs de projet . . . . . . . . . . . . . . . . . . . 6
2 Architecture Micro-service 8
2.1 Architecture micro-service . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Les Avantages de l’architecture des micro-services . . . . . . . . . . 10
2.1.2 Les inconvénients de l’architecture des micro-services . . . . . . . . 10
2.1.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Analyse et spécification des besoins 14
3.1 Définition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Les acteurs projet Identity . . . . . . . . . . . . . . . . . . . . . . . 15
v
3.1.1.1 Les acteurs projet Laboratory . . . . . . . . . . . . . . . 15
3.1.1.2 Les acteurs projet Talk . . . . . . . . . . . . . . . . . . . 16
3.2 Expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1.1 Projet Identity . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1.2 Projet Laboratory . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1.3 Projet Talk . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 Besoins non fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Vue globale du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 Vue globale du projet Talk . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Raffinement des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.1 Raffinement des cas d’utilisation du projet Identity . . . . . . . . . 20
3.4.2 Raffinement des cas d’utilisation du projet Laboratory . . . . . . . 22
4 Conception de notre solution 25
4.1 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Projet Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1.1 Diagramme de class . . . . . . . . . . . . . . . . . . . . . 27
4.2.1.2 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . 28
4.2.2 Projet Laboratory . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.2.1 Diagramme de class . . . . . . . . . . . . . . . . . . . . . 29
4.2.2.2 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . 30
4.2.3 Projet Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.3.1 Diagramme de class . . . . . . . . . . . . . . . . . . . . . 30
4.2.3.2 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Diagrammes séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5 Réalisation 35
5.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
vi
5.1.1 Environnement Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.1.1 Intellij IDEA Community Edtion . . . . . . . . . . . . . . 36
5.1.1.2 GIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.1.3 Postico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1.4 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1.5 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.2.1 Framework Play Scala . . . . . . . . . . . . . . . . . . . . 38
5.1.2.2 JSON Web Token . . . . . . . . . . . . . . . . . . . . . . 38
5.1.2.3 Test unitaires . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.2.4 Les pull-request . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.3 Mode de fonctionnement de l’application . . . . . . . . . . . . . . . 40
5.1.3.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1.3.2 Laboratory . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.3.3 Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Références 56
Annexes 58
vii
Table des figures
1.1 Dashboard de la méthodologie adopté au sien de la société . . . . . . . . . 6
2.1 Architecture micro-services et architecture monolithique . . . . . . . . . . 9
2.2 Ancient architecture monolithique d’Ubilab . . . . . . . . . . . . . . . . . . 11
2.3 Nouvelle architecture d’Ubilab . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Diagramme de cas d’utilisation globale du projet Talk . . . . . . . . . . . . 19
3.2 Digramme de cas d’utilisation de la rubrique administration pour le projet
Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Digramme de rubrique administration pour le projet Laboratory . . . . . . 23
4.1 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Diagramme de classe de la couche modelé de projet Identity . . . . . . . . 28
4.3 Diagramme de classe de la couche modelé de projet Laboratory . . . . . . 29
4.4 Diagramme de classe de la couche modelé de projet Talk . . . . . . . . . . 31
4.5 Diagramme de séquence de création d’un groupe . . . . . . . . . . . . . . . 33
5.1 Architecture logicielle du Framework Play scala . . . . . . . . . . . . . . . 38
5.2 Demande d’un pull-request . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 La liste des groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4 Les informations du groupe . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5 Les membres du groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6 Les membres du groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
viii
5.7 Étape 1/4 : Identité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.8 Étape 2/4 : informations complémentaires . . . . . . . . . . . . . . . . . . 43
5.9 Étape 3/4 : informations de contact . . . . . . . . . . . . . . . . . . . . . . 44
5.10 Étape 4/4 : mot de passe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.11 Personnaliser Ubilab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.12 Connexion à Ubilab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.13 Gestion du notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.14 Mode de prélèvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.15 List du catalogue d’examens . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.16 List des catégories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.17 Ajout d’une catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.18 Suppression d’une catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.19 Liste des catégories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.20 Rappels automatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.21 Image accueil application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.22 le mot du labo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.23 Interface principale pour Talk version web . . . . . . . . . . . . . . . . . . 52
5.24 Page chat dans le cas il n’y a pas des messages . . . . . . . . . . . . . . . . 53
5.25 Indiquer l’état d’un message envoyé . . . . . . . . . . . . . . . . . . . . . . 53
5.26 Cas réessayer d’envoyer un message . . . . . . . . . . . . . . . . . . . . . . 54
5.27 Interface pour un message non envoyé et si un utilisateur en train d’écrire . 54
A1 Exemple d’une requête GET et réponse du serveur . . . . . . . . . . . . . 2
B1 Architecture de système rabbitMQ . . . . . . . . . . . . . . . . . . . . . . 4
B2 Schéma éxhange de type fanout . . . . . . . . . . . . . . . . . . . . . . . . 5
B3 Schéma éxhange de type fanout . . . . . . . . . . . . . . . . . . . . . . . . 6
C1 Fonction onInit() et clearDatabase() . . . . . . . . . . . . . . . . . . . . . 8
C2 Sérialiser et désérialiser un objet JSON . . . . . . . . . . . . . . . . . . . . 9
C3 Fonction MakeUniqueInternalMail . . . . . . . . . . . . . . . . . . . . . . . 10
C4 Envoie et réception des message avec les Actors . . . . . . . . . . . . . . . 11
ix
Liste des tableaux
1.1 Acteurs et missions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Description scénariste du cas d’utilisation « Afficher les informations d’un
message» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Description scénariste du cas d’utilisation « Créer un utilisateur » . . . . . 22
3.3 Description scénariste du cas d’utilisation « Modifier logo de laboratoire » 24
1 Exemple d’une API REST (Méthodes HTTP, routes et descriptions) . . . . 2
x
Glossaire des acronymes
POC : Proof of concept - une preuve de la faisabilité.
SSH : Secure Shell.
SSL : Transport Layer Security.
API : Application Programmable Interface.
SGBDR : Système de Gestion de Base de Données Relationnelle
IDE : Integrated Development Environment.
TDD : Test Driven Development.
JWT : JSON Web Token.
HTTP : Hypertext Transfer Protocol .
REST : Representational State Transfe.
SMS : Short Message Service.
UML : Unified Modeling Language.
JSON : JavaScript Object Notation.
SVN : Subversion
XML : Extensible Markup Language
DAO : Data Access Object
URL : Uniform Resource Locator
TCP : Transmission Control Protocol
xi
Introduction Générale
La santé, c’est avant tout un secteur où l’humain, le patient, est au cœur de toutes les
considérations. Qui dit humain et santé dit relations humaines, et celles-ci sont d’autant
plus délicates que le contexte, si particulier, est bien souvent de mauvais augure.
Médecin, chirurgien, infirmière... autant de professions qui ne cessent de susciter des
vocations chaque jour, avec un seul et même but en ligne de mire : aider les patients et
prendre soin d’eux. Ainsi, en numérisant et en automatisant un certain nombre d’infor-
mations et de tâches, on décharge le personnel de santé de préoccupations évidentes[1].
C’est dans ce cadre que la société Silk cherche aujourd’hui à développer leurs produits
dédiés au pré-analytique en laboratoire et notamment aux manuels de prélèvements, dans
le domaine de santé et de la biologie médicale.
Dans le même contexte et pour améliorer l’expérience utilisateur, Silk pense à offrir à
ses clients un module du tchat s’appelle Talk ainsi regrouper les fonctionnalités d’Ubilab
en deux mirco-services.
En effet, Le présent rapport décrire les étapes de la mise en œuvre du projet et les
notions de base. Il est divisé en 5 chapitres. Le premier sera dédié au contexte général du
stage. Dans le second chapitre nous allons faire une étude sur architecture micro-service
dont nous expliquons architecture utiliser au cours de stage. Nous consacrons le troisième
chapitre à l’analyse des besoins fonctionnels et non fonctionnels de la solution avec une
spécification détaillée à l’aide des diagrammes UML (Unified Modeling Language). Dans le
quatrième chapitre, comporte la description l’architecture logicielle de notre solution ainsi
que la conception détaillée. Le dernier chapitre de présente l’environnement de travail et
les outils utilisés pour la réalisation de l’API(WebSocket, HTTP) ainsi qu’une présenta-
tion des fonctionnalités de l’application réalisée. Ce rapport s’achève par une conclusion
générale et les perspectives futures de ce travail.
1
Chapitre 1
Cadre du projet
Plan
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . 3
1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Méthodologie de développement . . . . . . . . . . . . . . . . . 4
1.4.1 Avantages de la méthode agile Scrum . . . . . . . . . . . . . . 5
1.4.2 Environnements mis en place . . . . . . . . . . . . . . . . . . . 5
1.4.3 L’ensemble des acteurs de projet . . . . . . . . . . . . . . . . . 6
2
CHAPITRE 1.Cadre du projet
Introduction
Dans ce présent chapitre nous présentons l’entreprise Silk, puis nous posons le contexte
et la problématique du projet pour enfin présenter la méthodologie de travail.
1.1 Présentation de l’organisme d’accueil
Cofondée en 2011 par Guillaume BADIN et Christophe DUBERNET DE BOSCQ,
amie depuis vingt ans qui sont passionnés par l’entrepreneuriat. Silk s’est d’abord spécia-
lisée dans le développement BtoB de sites Internet et d’applications mobiles, et en 2013,
Silk a lancé le travail sur un produit qui s’appelle Ubilab pour aider les laboratoires d’ana-
lyses médicales. Toujours à la pointe de technologie, Silk permet aujourd’hui aux gens
de laboratoire de gérer facilement et rapidement les informations pré-analytiques auprès
des professionnels de santé internes ou externes au leur laboratoire associe à plusieurs
services :
• Ubilab-Home : vous permet de gérer votre référentiel d’examens, votre manuel de
prélèvement et vos conventions de manière dématérialisée.
• Ubilab-Learning : vous aide dans la formation de vos collaborateurs. Vous pouvez
créer vos propres formations, importer vos formations existantes ou piocher dans le cata-
logue. Vous pourrez délivrer des attestations, des habilitations et effectuer vos suivis de
compétences.
• Ubilab-Result : utilise notre infrastructure serveur dont l’hébergeur est agréé par
l’ASIP Santé. Cela nous permet d’envoyer les résultats d’examen (ex : INR) aux profes-
sionnels de santé via nos applications mobiles (notification push) en vous affranchissant
des SMS non sécurisés.
• Ubilab-Visit : accompagne les IDE lors de leurs tournées. Les IDE peuvent scanner
tous types de documents (ordonnance, carte vitale, carte de mutuelle, carte d’identité,
attestation de sécurité sociale, etc.) et les envoyer au laboratoire depuis le domicile du
patient [2].
1.2 Problématique
Depuis le début, Silk a su que biologie médicale étant l’un de grand oubliés du vi-
rage numérique. C’est pour ça, il a souhaité proposer une approche stratégique dans les
logiciels médical. Pendant quel mois, en France Silk a pris une part prépondérante sur
les services dédié aux professionnels de santé avec plus de 1600 laboratoires équipés. Le
Rapport de Projet de Fin d’études 3
CHAPITRE 1.Cadre du projet
nombre des utilisateurs de produit "Ubilab" augmente chaque année de manière exponen-
tielle. Chaque laboratoire à ses propres utilisateurs que ce soit biologiste, administrateur,
infirmier, patient, etc.
Effectivement, comme toute autre start-up ces fonctionnalités doivent correspondre et
satisfaire aux l’ensembles besoins et demandes de ses clients pouvoir garantir les conti-
nuations de leurs abonnements.
D’autre part, concernent au nombre des utilisateurs qui augmente chaque jour et par
rapport à la relation entre certain profile il y’a toujours pas un moyen de communication
interne dans “Ubilab” ce qui empêche de se contacter directement dans application mobile
ou même dans l’application web et qui les provoqué à se déplacer sur place pas mal des
fois pour communiquer.
Pour faire face à ces problèmes, la société Silk cherche aujourd’hui à mettre en place
un module de chat qui relient ces utilisateurs et permettent de communiquer en temps
réel et ainsi que faire la refonte et amélioration ergonomique d’application “Ubilab”.
1.3 Objectifs
La société Silk cherche aujourd’hui à mettre en place un module de chat ainsi qu’amé-
liorer leur produit “Ubilab”.
Les objectifs de ce projet sont donc de :
• Répondre au besoin de certains clients.
• Faire une application plus performante plus ergonomique avec plus de fonctionnalités
dont le client a vraiment besoin.
• Ajouter un module de tchat interne à l’application vis-à-vis des laboratoires.
1.4 Méthodologie de développement
Dédiées à la gestion de projets informatiques, les méthodes agiles reposent sur une
approche itérative et incrémentale qui s’adaptent parfaitement aux futurs besoins du
client [3].
Les méthodes agiles dirigèrent vers intégrer le client dans la réalisation du projet afin
d’avoir un produit de haute qualité dans à brève échéance.
Rapport de Projet de Fin d’études 4
CHAPITRE 1.Cadre du projet
Il existe plusieurs méthodologies dans la famille comme la méthode RUP, la méthode
XP, la méthode Scrum, etc.
Pour la gestion de ses projet la société Silk utilise la méthode, car à ce jour la méthode
agile est la méthode la plus pratiquer parmi toutes les méthodes agiles existantes. C’est
une méthode agile principalement basée sur des itérations de courtes durées appelées
Sprints.
1.4.1 Avantages de la méthode agile Scrum
La méthode agile Scrum a plusieurs avantages comme :
— Avoir une idée claire sur déférents étapes du projet : une vue d’ensemble sur l’évo-
lution du projet du l’étape développement vers étape production.
— Avoir une flexibilité totale du projet : le client peut avoir une flexibilité totale au
niveau de la définition des priorités selon leur besoins.
— Avoir la meilleure qualité : une évaluation périodique de l’avancement du projet et
sa permet de garantir une meilleure qualité du produit.
— Avoir une planification adaptée au votre besoin : une planification détaillée à court
terme et à long terme.
1.4.2 Environnements mis en place
Dans la société Silk, il y’a deux environnements distincts seront mis en place :
• Environnement de développement : dans lequel travaux de développement se-
ront conduits.
• Environnement de production : dans lequel sera placée la version validée à la
fin du sprint.
Comme montre la figure ci-dessus :
Rapport de Projet de Fin d’études 5
CHAPITRE 1.Cadre du projet
Figure 1.1 – Dashboard de la méthodologie adopté au sien de la société
1.4.3 L’ensemble des acteurs de projet
Nous présentons le tableau ci-dessous l’ensemble des acteurs participants au dévelop-
pement des différentes étapes du projet :
Rapport de Projet de Fin d’études 6
CHAPITRE 1.Cadre du projet
Table 1.1 – Acteurs et missions
Rôle Acteurs Mission
Équipe Mohamed BOUBAYA - Étude et conception et mise en place les
modules.
- Conception et développement du backend
de module tchat.
Hubert RAYNAUD - Aide à la conception et le développement
les modules.
Lounès BADJI - Conception et développement de la couche
présentation pour le partie web.
Florian GALLE - Création des pages Web et les pages mo-
biles.
Benjamin BONNETTO - Conception et développement de la couche
présentation pour le partie mobile.
Scrum Master Guillaume BADIN - Assurer que les valeurs et les principe de
Scrum sont bien respectés.
Product Owner Christophe DUBERNET - Définition validation des fonctionnalités dé-
veloppées.
Conclusion
Dans ce premier chapitre, nous avons présenté le contexte général du projet. Nous
avons commencé, tout d’abord, par une présentation de l’entreprise d’accueil Silk, ensuite
nous avons introduit le contexte et la problématique du projet, enfin, nous avons consa-
cré la dernière pratique la méthodologie adoptée ainsi l’ensemble environnements mis en
place.
Rapport de Projet de Fin d’études 7
Chapitre 2
Architecture Micro-service
Plan
2.1 Architecture micro-service . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Les Avantages de l’architecture des micro-services . . . . . . . . 10
2.1.2 Les inconvénients de l’architecture des micro-services . . . . . . 10
2.1.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8
CHAPITRE 2. Architecture Micro-service
Introduction
Ce chapitre serai devise en deux parties : la première dans lequel nous allons détailler
la conception, les avantages et l’inconvénient de l’architecture micro-service. Dans second
partie on s’intéresserai à la différents compostant utiliser pour réaliser le solution micro-
services du projet "Ubilab".
2.1 Architecture micro-service
L’architecture des micro-services c’est une méthode utiliser pour développement de
systèmes logiciels. En fait, cette architecture permet de traiter une application comme un
ensemble des petits services chaque service considérer comme un projet à part. Comme
présente la figure ci-dessous la différence entre architecture micro-service et architecture
monolithique :
Figure 2.1 – Architecture micro-services et architecture monolithique
L’architecture micro-services développe une application comme un ensemble de petits
services. Chaque service fonctionne moyennant son propre processus qui communique avec
des mécanismes légers. Les services sont développés autour des compétences métiers qui
sont déployés d’une façon indépendante par un processus automatisé. Ils sont autonomes
Rapport de Projet de Fin d’études 9
CHAPITRE 2. Architecture Micro-service
et isolés mais aussi ils peuvent communiquer entre eux pour pourvoir créer l’ensemble
du fonctionnalités nécessaires. Les micro-services sont généralement gérer par des petites
équipes avec susamment d’autonomie. Chaque équipe peut modifier ou supprimer l’im-
plémentation d’un service dans un micro-services avec un impact minimal sur le reste de
système. Ils ont plusieurs avantages et inconvénients sa dépend du cas dans lequel ils sont
utilisés.
2.1.1 Les Avantages de l’architecture des micro-services
Dans la suite, nous présentons l’ensemble des avantages puisqu’il est nécessaire de
connaître notre micro-service à quoi être capable de nous offrir et ses principaux avantages
sont :
• Limite les problèmes de la complexité : les services individuels peuvent être
développés et mise en œuvre plus rapidement et aussi qu’ils sont assez simples de
les comprendre et à maintenir.
• Optimise les ressources : l’architecture micro-services permet à d’optimiser les
ressources consacrées aux applications car chaque service est développé de maniérer
indépendante par une équipe dédiée.
• Rapidité de déploiement les nouvelles fonctionnalités : les micro-services
rendent les déploiements des nouvelles fonctionnalités et les mises à jour très rapide
et très facile.
2.1.2 Les inconvénients de l’architecture des micro-services
Les architectures de micro-services, malgré leurs avantages font l’objet de critiques à
cause de l’ensemble des inconvénients tell que :
• Longue durée de lancement d’application : pour démarrer les applications à
base de micro-services nous devons de lancer chaque service à part.
• Incohérence de données : Les transactions commerciales mettant à jour les don-
nées de plusieurs entreprises à la fois sont assez courantes. Ce type de transaction
est simple à mettre en œuvre dans une application monolithique car il n’y a qu’une
seule base de données. Toutefois, dans une application basée sur les micro-services,
différentes bases de données appartenant à différents services devront être mises à
jour [4].
Rapport de Projet de Fin d’études 10
CHAPITRE 2. Architecture Micro-service
• Complexité de faire les tests : les tests peuvent devenir très compliqués et très
fastidieux à cause du déploiement distribué.
Les retours d’expériences sur ce type d’architecture sont très positifs, donc ils devient un
standard pour les grosses applications comme Amazone, Netflix, etc.
2.1.3 Solution proposée
La figure 2.2 illustre l’architecture globale utiliser par "Ubilab" :
Figure 2.2 – Ancient architecture monolithique d’Ubilab
Comme présenté dans la figure, le projet "Ubilab" était basé sur architecture mono-
lithique dans lequel ensemble de fonctionnalité sont localiser dans seul projet qui utiliser
PostgresSQl et MongoDB comme deux bases de données.
Et pour améliorer cet architecture, nous avons choisi d’utiliser une architecture base
sur les micro-services comme s’explique la figure ci-dessus.
Rapport de Projet de Fin d’études 11
CHAPITRE 2. Architecture Micro-service
Figure 2.3 – Nouvelle architecture d’Ubilab
Cette architecture contient principalement :
• Partie serveur :
– Un broker RabbitMq (voir annexe A) : permet d’assurer la communication
entre les ensembles des projets. En termes simples, il permet à un « Publisher
» d’envoyer un message et permet à un « consommer » d’écouter ces messages.
– Les micro-services (Identity, Laboratory, Talk) : les micro-services sont indé-
pendant.
– Une base donnée PostgresSQL : permet de partager les informations entre les
projets.
• Partie Client :
– Partie Web : désigne un logiciel applicatif hébergé (Silk utilise Clever-cloud
comme un hébergeur des différentes micro-services) sur n’importe quelle un
serveur et accessible via un navigateur web (Chrome, Firefox, Microsoft Edge,
etc.).
Rapport de Projet de Fin d’études 12
CHAPITRE 2. Architecture Micro-service
– Partie mobile : désigne un logiciel applicatif développé pour un appareil mobile
(smartphones) ce dernier utilise n’importe quel système d’exploitation mobile :
Android, IOS.
Et pour communiquer entre la partie client (web, mobile) et la partie serveur nous avez
utilisé les API REST et API Websocket (voir annexe B).
Conclusion
Dans ce chapitre, nous avons commencé par comprendre l’architecture micro-service
par situer leurs avantages et leur les inconvénients, ensuite en à étudier l’architecture
utiliser dans notre solution. Le chapitre suivant consacré à la réalisation notre solution.
Le chapitre suivant consacré à l’analyse et spécification des besoin.
Rapport de Projet de Fin d’études 13
Chapitre 3
Analyse et spécification des besoins
Plan
3.1 Définition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Les acteurs projet Identity . . . . . . . . . . . . . . . . . . . . . 15
3.2 Expression des besoins . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Besoins non fonctionnel . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Vue globale du système . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 Vue globale du projet Talk . . . . . . . . . . . . . . . . . . . . 18
3.4 Raffinement des cas d’utilisation . . . . . . . . . . . . . . . . . 20
3.4.1 Raffinement des cas d’utilisation du projet Identity . . . . . . 20
3.4.2 Raffinement des cas d’utilisation du projet Laboratory . . . . . 22
14
CHAPITRE 3. Analyse et spécification des besoins
Introduction
Ce chapitre sera divisé en deux parties : dans lequel nous identifions les acteurs interve-
nants dans chaque micro-service ensuite nous allons commencer par identifier les ensembles
de besoins fonctionnels et non fonctionnels de notre solution. Une fois faite cette étape
nous mettrons en valeur la deuxième partie dans lequel nous modélisions ces besoins à
travers les diagrammes de cas d’utilisation de l’UML.
3.1 Définition des acteurs
Avant commencer de situer l’ensemble de besoins fonctionnels et non fonctionnels il
faut d’abord présenter les acteurs qui sont en contact direct avec chaque service et profitent
de différents accès aux données.
3.1.1 Les acteurs projet Identity
Le seul actionneur dans le projet Identity c’est les administrateurs de compte "Ubilab"
qui permet de faire :
– La gestion d’utilisateurs quel que soit leurs rôles.
– La gestion des groupes.
– La gestion d’archive utilisateurs.
– La gestion de conventions.
3.1.1.1 Les acteurs projet Laboratory
Dans le projet Laboratory il y’a que les administrateurs de compte "Ubilab" qui sont
responsable à :
– La gestion de permission d’accès.
– La gestion d’abonnement.
– Configuration d’examens.
– Configuration communication dans "Ubilab".
Rapport de Projet de Fin d’études 15
CHAPITRE 3. Analyse et spécification des besoins
3.1.1.2 Les acteurs projet Talk
Les acteurs de Talk principalement sont :
• Les administrateurs sont responsables à :
– La gestion de discussion de groupe ("Channel général", "Channel support")
• Les personnels de laboratoire (les infirmiers, les médecines, les biologistes, etc.) sont
responsables de :
– Les réaction sur les messages.
– Les partage de fichiers.
– Les envois et réceptions de messages.
3.2 Expression des besoins
Cette étape vise à déterminer la vision globale de notre projet en mettant en valeurs
les besoins fonctionnels et non fonctionnels.
3.2.1 Besoins fonctionnels
3.2.1.1 Projet Identity
Les besoins fonctionnels de projet Identity sont :
• Gestion des utilisateurs : L’application doit permettre aux administrateurs de
créer un utilisateur quel que soit son rôle (les infirmiers, les médecines, les biolo-
gistes, etc.), modifier ses informations, le supprimer, mettre en pause ou archiver
l’utilisateurs, envoyer le rappel, ajouter un commentaire, supprimer un commen-
taire, rechercher les utilisateurs selon plusieurs filtre (sexe, profile, groupe, téléphone,
adresse ,etc.) et exporter la liste des utilisateurs sous format Excel.
• Gestion des groupes : L’application doit permettre aux administrateurs de créer
un groupe, modifier ses informations, le supprimer, ajouter un utilisateur à ce
groupe, enlever un utilisateur à ce groupe et rechercher un ou plusieurs groupes.
• Gestion des conventions : L’application doit aussi permettre aux administrateurs
d’attacher une convention papier signe a une convention, voir la convention papier
signée, remplacer la convention papier signée et annuler la signature papier.
Rapport de Projet de Fin d’études 16
CHAPITRE 3. Analyse et spécification des besoins
3.2.1.2 Projet Laboratory
Les besoins fonctionnels de projet Laboratory sont :
• Gestion de l’interface web : Laboratory permet aux administrateurs de modi-
fier logo de laboratoire, modifier le favicon de l’application web, choisir le type de
connexion, activer la connexion patiente, choisir la durée maximum de session, gérer
les permissions d’accès et gérer l’abonnement.
• Gestion de la configuration du manuel : Laboratory offre aux administrateurs
possibilités de créer nouvelle catégorie, supprimer la catégorie, modifier la catégorie
et choisir une version du manuel des fiches.
• Gestion de la communication dans Ubilab : Laboratory permet aux adminis-
trateur d’ajouter mail de contact, ajouter texte de contact, personnaliser le mail
envoi de s’identifiants, ajouter une adresse mail d’envoi en copie cachée, tester l’en-
voi mail envoi des identifiants, personnaliser le SMS d’envoi des identifiants, tester
l’envoi SMS, activer le notifications automatique de rappel, ajouter le période notifi-
cation automatique, personnaliser le mail de rappel, personnaliser le SMS de rappel,
tester l’envoi de SMS et Email de rappel et afficher le facturation des SMS.
• Gestion d’application mobile : Il offre aussi aux administrateurs possibilités
de modifier image d’accueil dans l’application, modifier le mot du labo, ajouter
lien vers serveur de résultat professionnels, activer l’accès au serveur de résultats
professionnels sur l’application, activer l’accès au service externe de prise de rendez-
vous et ajouter lien vers le service externe de prise de rendez-vous.
3.2.1.3 Projet Talk
Les besoins fonctionnels de micro-service Talk sont :
• Gestion des messages : Talk offre aux personnels de laboratoire possibilités d’en-
voyer des messages instantané, réceptions de messages, activer les notifications, ré-
agir à un ou plusieurs messages et partager des fichiers.
• Gestion de discussion de groupe : Talk permet aux administrateurs d’ajouter
ou supprimer un ou plusieurs utilisateurs à une discussion de groupe.
• Gestion des conventions : L’application doit aussi permettre aux administrateurs
d’attacher une convention papier signe a une convention, voir la convention papier
signée, remplacer la convention papier signée et annuler la signature papier.
Rapport de Projet de Fin d’études 17
CHAPITRE 3. Analyse et spécification des besoins
3.2.2 Besoins non fonctionnel
Il s’agit d’ensemble des contraintes technique caractérisent l’ensemble de micro-services
en matière de performance. Nous citons essentiellement :
• Modularité : Chaque micro-service doit offrir une modularité de paramétrage à
ses utilisateurs pour pouvoir l’adapter à des besoins.
• Sécurité : L’application doit garantie de contrôles de sécurité réservant l’accès aux
données aux utilisateurs appropriés. Donc, il faudrait assurer la bonne gestion des
droits d’accès ainsi que les rôles.
• Performance : Chaque micro-service doit disposer un temps de réponse optimal
à travers le respect des bonnes pratiques de développement logiciel et par la pré-
paration de l’environnement matériel adéquat (bande passante suffisante, serveurs
performants, etc.).
3.3 Vue globale du système
Cette étape consacrée à déterminer la vision globale de notre projet, mais dans notre
cas en à choisir de présenter que la vue globale du projet Talk car ce dernier contient
plusieurs acteurs.
3.3.1 Vue globale du projet Talk
Le diagramme ci-dessous illustre le diagramme de cas d’utilisation global de projet
Talk. Chaque acteur dispose ensemble des permissions qui lui sont accordées ainsi d’un
nombre de fonctionnalités relatives à son rôle.
Rapport de Projet de Fin d’études 18
CHAPITRE 3. Analyse et spécification des besoins
Figure 3.1 – Diagramme de cas d’utilisation globale du projet Talk
La description scénariste du cas d’utilisation « Afficher les informations d’un message
» est présentée dans le tableau ci-dessous.
Table 3.1 – Description scénariste du cas d’utilisation « Afficher les informations d’un
message»
Cas d’utilisation : Afficher les informations d’un message.
Résumé : Un utilisateur peut visualiser l’information de chaque message.
Acteurs : Utilisateur.
Pré-condition : L’utilisateur est authentifié et abonnée à une Channel Talk .
Scénario nominal :
1- L’utilisateur clique sur le menu puis choisir « Talk ».
2- L’utilisateur Clique une première fois sur un message pour afficher ensembles
des informations.
3- Les informations d’un message sont affichées.
Scénarios alternatifs :
Si l’utilisateur clique deux fois successives sur le message les informations appa-
raissent très vite et disparaissent.
Rapport de Projet de Fin d’études 19
CHAPITRE 3. Analyse et spécification des besoins
3.4 Raffinement des cas d’utilisation
Après avoir présenté le diagramme de cas d’utilisation global de projet Talk, Nous
allons maintenant situer les diagrammes des cas d’utilisation raffinés pour chaque projet.
3.4.1 Raffinement des cas d’utilisation du projet Identity
La figure 3.2 présente le digramme de cas d’utilisation de la rubrique administration
pour le projet Identity.
Rapport de Projet de Fin d’études 20
CHAPITRE 3. Analyse et spécification des besoins
Figure 3.2 – Digramme de cas d’utilisation de la rubrique administration pour le projet
Identity
La description scénariste du cas d’utilisation « Créer un utilisateur » est présentée
dans le tableau ci-dessous.
Rapport de Projet de Fin d’études 21
CHAPITRE 3. Analyse et spécification des besoins
Table 3.2 – Description scénariste du cas d’utilisation « Créer un utilisateur »
Cas d’utilisation : Créer un utilisateur.
Résumé : Un administrateur peut créer un utilisateur (Administrateur, coursier,
biologiste, médecin, client, sage-femme, etc..) en spécifiant les ensemble informations
relatives à ce dernier.
Acteurs : Administrateur.
Pré-condition : L’administrateur est authentifié.
Scénario nominal :
1- L’administrateur se rend à la page création d’un nouvel utilisateur.
2- Le système affiche le pop-up qui contient quatre étapes.
3- L’administrateur saisit l’ensemble des informations nécessaires et choisit de les
enregistrer. Le système enregistre le nouvel utilisateur, ensuite enregistre dans
archive l’action de création d’un nouvel utilisateur pour cet administrateur
et enfin réaffiche la page création d’un nouvel utilisateur réinitialisée avec un
message de succès en mémé temps le système envoie un Email qui contient
l’identifiant et mots de passe associe à ce nouvel utilisateur.
Scénarios alternatifs :
E1 : Erreur dans les informations saisies dans chaque étape.
1- Le système affiche le message d’erreur.
2- Le système affiche le pop-up qui contient quatre étapes.
3.4.2 Raffinement des cas d’utilisation du projet Laboratory
La figure 3.3 illustre le digramme de cas d’utilisation de la rubrique administration
pour le projet Laboratory.
Rapport de Projet de Fin d’études 22
CHAPITRE 3. Analyse et spécification des besoins
Figure 3.3 – Digramme de rubrique administration pour le projet Laboratory
Le tableau ci-dessous décrit le scénario du cas d’utilisation « Modifier logo de labora-
toire »
Rapport de Projet de Fin d’études 23
CHAPITRE 3. Analyse et spécification des besoins
Table 3.3 – Description scénariste du cas d’utilisation « Modifier logo de laboratoire »
Cas d’utilisation : Modifier logo de laboratoire
Résumé : Un administrateur peut modifier logo de leur laboratoire en choisissant
une image qu’a la taille 96*649px ou 96*96px.
Acteurs : Administrateur
Pré-condition : L’administrateur est authentifié
Scénario nominal :
1- L’administrateur se rend à la page personnaliser Ubilab.
2- Le système affiche le page.
3- L’administrateur télécharge logo associe à leur laboratoire.
4- Le système envoie l’image à un micro-service qui s’appelle Ubilab-Uplod dans
la quel en enregistre l’image dans le serveur ensuite Ubilab-Uplod envoie au
système URL associe à cette image et enfin le système enregistre cette URL
et afficher le nouveau logo.
Scénarios alternatifs :
E1 : Erreur dans le téléchargement de logo.
• Le système affiche le message d’erreur.
Conclusion
Dans ce chapitre, nous avons commencé par identifier l’ensemble des acteurs de notre
application ainsi que les différents besoins fonctionnels et non fonctionnels. Donc après
l’étude développée précédemment nous guide dans le chapitre qui suivent : la conception
et la réalisation de notre solution.
Rapport de Projet de Fin d’études 24
Chapitre 4
Conception de notre solution
Plan
4.1 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Projet Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 Projet Laboratory . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.3 Projet Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Diagrammes séquences . . . . . . . . . . . . . . . . . . . . . . . 32
25
CHAPITRE 4. Conception de notre solution
Introduction
Avant de commencer la réalisation ou le développement de chaque projet qui répond aux
besoins demandés il est nécessaire de faire sa conception. Dans cette étape, nous allons
détailler l’architecture logicielle de notre solution ainsi que la conception détaillée.
4.1 Architecture logicielle
La figure 4.1 représente l’architecture logicielle commune des différents micro-services.
Figure 4.1 – Architecture logicielle
L’architecture de la figure 4.1 est composée de
• Couche d’accès aux donnés (DAO) :
Cette couche permet d’implémenter le pattern DAO. Elle contient l’ensemble des
éléments permettant l’accès aux données de la base. Cette couche interroge les bases
Rapport de Projet de Fin d’études 26
CHAPITRE 4. Conception de notre solution
reliées avec elle indépendante de la logique métier et offre à la couche logique métier
toutes les données nécessaires.
• Couche métier :
C’est la couche responsable à la logique métier. Cette couche est indépendante de
toute forme d’interface avec l’utilisateur. Elle interagit avec la couche service et la
couche accès aux données et pour fournir le résultat final des exécutions qui sera
ensuite transmis vers couche service.
• Couche service :
Cette couche est responsable de la communication entre la couche interface utilisa-
teur et la logique métier. Elle est constituée d’un ensemble de Web services englobant
les traitements métier.
• Sérialiseurs des modèles métiers :
Les sérialiseurs des modèles métiers c’est un composant obligatoire du Framework
Play2.6 scala. Ils permettent aux données complexes tels que les instances du modèle
d’être convertis en types de données native scala qui peuvent par la ensuite être
facilement rendues en format XML, JSON ou autres types de contenu.
• Couche interface utilisateur :
C’est la couche qui offre à l’utilisateur de piloter l’application. Elle interagit direc-
tement avec la couche service pour récupérer les données nécessaires et pour lancer
ensemble des traitements. La couche interface utilisateur a été utiliser avec l’utili-
sation du pattern Model View Controller (MVC).
4.2 Conception détaillée
Analyse et spécification des besoin de chaque micro-services établies dans le chapitre
précédent vont nous permettre d’identifier les différentes classes. En utilisant les dia-
grammes du langage UML, nous allons entamer dans cette partie la conception détaillée
de notre solution. Par soucis de simplification, nous allons présenter des exemples de
classes pour chaque micro-service.
4.2.1 Projet Identity
4.2.1.1 Diagramme de class
La figure 4.2 illustre présente le digramme de class des entités utiliser en projet Talk.
Rapport de Projet de Fin d’études 27
CHAPITRE 4. Conception de notre solution
Figure 4.2 – Diagramme de classe de la couche modelé de projet Identity
• UserSearch : L’entité qui contient l’ensemble des informations associe à utilisateur.
• Role : Chaque utilisateur peut avoir plusieurs rôles.
• UserGroupe : Cette classe représente l’ensemble des groupes qu’utilisateur peut
les joindre.
• Laboratory : Cette entité qui représente laboratoire.
• ProfileRight : Cette classe présente ensemble de droite associe à chaque profil.
• User : Classe qui représente l’utilisateur de projet Identity.
4.2.1.2 Schéma relationnel
• User(idUser, firstName, lastName, email, #id_laboratory, #id_profile)
• UserSearch(idUserSearch, firstName, lastName, #id_user )
• Role(idRole)
• UserGroup(idUserGroup, name, created, description)
• Profile(idProfile, name)
• ProfileRight(idProfileRight, name, display)
• Laboratory(idLaboratory, name, sikey, created)
Rapport de Projet de Fin d’études 28
CHAPITRE 4. Conception de notre solution
• User_role(#user_id, #role_id)
• UserGroup_user(#id_use_group, #id_user)
• ProfileRigh_Profile(#id_profile_right, #id_profile)
4.2.2 Projet Laboratory
4.2.2.1 Diagramme de class
La figure 4.3 illustre présente le digramme de class des entités utiliser en projet Labo-
ratory
Figure 4.3 – Diagramme de classe de la couche modelé de projet Laboratory
• LaboratoryConfig : Cette entité contient les ensembles de configuration associe à
un laboratoire.
• LaboratoryGroup : Cette classe désigne ensemble des groupes des laboratoires.
• LaboratoryOffice : Cette classe présente ensembles des bureaux diffuse dans tout
le monde.
• AnalysisFieldToHide : Cette entité présente ensemble des analyses associe à
chaque profil.
• AnalysisField : Cette classe présente Information des analyses.
Rapport de Projet de Fin d’études 29
CHAPITRE 4. Conception de notre solution
• UserGroupRight : Cette entité désigne ensemble des droites associe à chaque
groupe dans laboratoire.
4.2.2.2 Schéma relationnel
• LaboratoryConfig(id, analysisImageCdnUrl, welecomeMailText, created, weleco-
meSMStext, homeSMSText, homeImageCdnUrl, maxSessionTime, hasViste, add-
LaboName, #id_laboratory).
• LaboratoryGroup(id, name, sikey, email).
• UserGroupRight(id, name, display, #idLaboratory).
• AnalysisFieldToHide(id, created, #field, #id_laboratory).
• AnalyssisField(code, name, description).
• LaboratoryOffice(id, name, isTechnicalPlatform, address, codePostal,sity,
#id_laboratory) .
• Laboratory(idLaboratory, name, sikey, isCussomer, urlIOS, urlandroid, created,
#id_laboratoryGroup ).
4.2.3 Projet Talk
4.2.3.1 Diagramme de class
La figure 4.2 illustre présente le digramme de class des entités utiliser en projet Talk :
Rapport de Projet de Fin d’études 30
CHAPITRE 4. Conception de notre solution
Figure 4.4 – Diagramme de classe de la couche modelé de projet Talk
• Room : Cette classe représente une salle de discussion où on peut échanger textes ou
fichier sur le sujet tous les utilisateurs qu’on veut cette "Room" peut être soit salle de
discussion direct "OneToOneChannel" (contient maximum deux utilisateurs), soit
salle de discussion privé "PrivateChannel" ou bien salle discussion public "Channel".
• Message : Cette entité décrit ensemble des messages envoyer par utilisateur vers
les salles de discussion.
• Profile : Chaque utilisateur posséde un profil (sage-femme, IDE, médecine, admi-
nistrateur, etc.)
• Reaction : L’utilisateur peut réagir à un message par un réaction.
• Session : en créer l’entité Session pour indiquer le période pendant laquelle l’utilisa-
teur et bien connecter à notre projet et sa nous permettront de facilité distribution
de message à chaque salle discussion dans laquelle l’utilisateur a été abonné.
• User : Classe qui représente l’utilisateur de projet Talk.
Rapport de Projet de Fin d’études 31
CHAPITRE 4. Conception de notre solution
4.2.3.2 Schéma relationnel
Le schéma relationnel est constitué les différents schémas de tables de base de données.
Voici les schémas relationnes de projet Talk :
• Room (idRoom, name, isPublic, isSupport, isGeneral)
• Message(idMessage, sendDate, text)
• User(idUser, firstName, lastName, image ,#Id_profile)
• Profile(idProfile, name)
• Session(idSession)
• Reaction(idReaction,value,#id_message)
• Message_Room(#IdMessage, #id_room)
• Room_Session(#idRoom, #id_session )
• User_Room(#idUser, #Id_room )
• User_Reaction(#idUser, #Id_reaction )
4.3 Diagrammes séquences
Le diagramme 4.4 illustre présente le diagramme de séquence de création d’un groupe :
Rapport de Projet de Fin d’études 32
CHAPITRE 4. Conception de notre solution
Figure 4.5 – Diagramme de séquence de création d’un groupe
Le diagramme séquence ci-dessus explique les étapes de création d’un groupe par
ClientHttp Web d’un laboratoire. Ce dernier doit saisir l’ensemble des formations néces-
saires "groupToCreate". Les données saisies seront envoyées dans une requête HTTP vers
GroupController.
Si les informations sont valides et l’administrateur est bien authentifié, le Controller fait
appelle à la méthode qui createGroup qui se trouve dans la couche métier (GroupSer-
viceWrite).Par la suite cette méthode fait un autre appelle pour une autre méthode qui
s’appelle getGroup qui permet de vérifier si le nom de groupe existe déjà dans notre base
donnée si non GroupServiceWrite envoie notre objet vers RabbitMQ (voir Annexe pour
enregistrer dans la base de données associé à l’archive et envoie un "Int" a GroupControl-
ler qui lui informe que la création est bien passé. Par la suite celui-ci envoie un réponse
HTTP avec un statuts 200.
Si le nom du groupe excite déjà le GroupServiceWrite envoie une exception à GroupCon-
troller et lui envoie à ClientHttp une réponse HTTP avec un statuts 417 "Expectation
Failed".
Dans l’autre cas :
- Si ClientHttp n’est pas un administrateur, GroupController envoie à ClientHttp une
Rapport de Projet de Fin d’études 33
CHAPITRE 4. Conception de notre solution
réponse HTTP avec un statuts 401 "Unauthorized".
- Si le format des données saisie est invalide, GroupController envoie à ClientHttp une
réponse HTTP avec un statuts 417 "Expectation Failed".
Conclusion
Tout au long de ce chapitre, nous avons étudié l’architecture logiciel et la conception de
notre solution. Dans un premier lieu, nous avons décrire l’architecture de notre application
qui définit la cohérence entre les différentes couches. Par la suite, nous avons détaillé notre
conception à travers de classes pour chaque micro-services et de séquences relatives à notre
solution. Le chapitre suivant consacré à la réalisation notre solution.
Rapport de Projet de Fin d’études 34
Chapitre 5
Réalisation
Plan
5.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . 36
5.1.1 Environnement Logiciel . . . . . . . . . . . . . . . . . . . . . . 36
5.1.2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.3 Mode de fonctionnement de l’application . . . . . . . . . . . . 40
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
35
CHAPITRE 5. Réalisation
Introduction
Après avoir traité la partie conception de notre travail. L’étape suivante, c’est la réalisa-
tion. Nous commencerons par expliquer nos choix technologiques nous concluons par la
présentation des interfaces réalisées.
5.1 Environnement de travail
Nous allons présenter dans cette partie les logiciels et les technologies que nous avons
utilisés pour la réalisation notre solution.
5.1.1 Environnement Logiciel
5.1.1.1 Intellij IDEA Community Edtion
Intellij IDEA Community est un environnement de développement intégré (IDE) dé-
veloppé par la société tchèque JetBrains et utilisé pour la programmation en Scala, Ja-
vaScript, Ruby, etc. Il fournit une analyse de code, un débogueur graphique, un testeur
d’unité intégrée et s’intègre parfaitement avec les systèmes de contrôle de version tel
que SVC ou GIT. Cet IDE soutient essentiellement le développement Web avec Scala.
Multi-plateforme, Intellij admet deux éditions une Community et une Professional (sous
licence)[5].
5.1.1.2 GIT
Git est un logiciel de gestion de versions décentralisé. Il est conçu pour être efficace
tant avec les petits projets que les plus importants[6]. Créé par Linus Torvalds, auteur du
noyau Linux, Git a spécialement été créé pour le développement du noyau linux [7]. Ces
principaux atouts sont :
• Une architecture décentralisée : contrairement à des outils comme Apache subversion
(SVN) ou Git fonctionne de décentralisée. Sur Son disque dur, Chaque collaborateur
détient une copie du projet avec tout son historique. Les ensembles des collabora-
teurs du projet peuvent se partager les données de projet sans passer directement
par un serveur.
• Des sites communautaires : des sites Web comme GitHub, GitLab ou Bitbucket ont
mis en place un espace associe aux utilisateurs de Git. Grace à dépôt à distance, Il
Rapport de Projet de Fin d’études 36
CHAPITRE 5. Réalisation
permet aux collaborateurs de visualiser le projet, consulter les modifications ainsi
que commenter des lignes décode.
• Des interfaces graphiques : des interfaces graphiques pour Git permettent aux utili-
sateurs de faciliter son utilisation en prenons comme exemple : SourceTree, Tortoi-
seGit, giKt, etc. Ainsi qu’ il y’a des plugins intégrés dans des IDE.
Pour ce projet, nous avons utilisé SourceTree comme interface graphique.
5.1.1.3 Postico
Postico est un outil destiné à l’administration des bases de données de Postgresql. Cet
outil propose une interface graphique comme alternative à l’interpréteur de commande
fournis avec Postgresql. Il permet de gérer plusieurs serveurs de base de données et propose
différentes méthodes d’authentification (identifiant/mot de passe, SSL, tunnel SSH)[8].
5.1.1.4 Postman
C’est un logiciel où aussi peut être un plugin dans le navigateur Chrome qui permet
de faire des tests sur les services Web REST. Il permet de créer facilement des requêtes
HTTP simples ou complexes, ainsi que les enregistrer et d’analyser les réponses envoyées
par l’API.
5.1.1.5 PostgreSQL
PostgreSQL est un système de gestion de base de données relationnelle et objet. L’une
des principales qualités de PostgreSQL est d’être un logiciel gratuit et open source. Post-
greSQL possède de nombreuses caractéristiques faisant de lui un SGBDR robuste. Il dis-
pose d’interface graphique, des bibliothèques facilitant l’accès aux données à partir des
programmes écrit en (JAVA, C, C++, Perl, etc) et d’une API ODBC permettant à n’im-
porte quelle application supportant ce type d’interface d’accéder à des bases de données
de type PostrgreSQL[9].
5.1.2 Technologies
Les technologies utilisées au cours de développement de notre solution sont :
Rapport de Projet de Fin d’études 37
CHAPITRE 5. Réalisation
5.1.2.1 Framework Play Scala
Play est un Framework Web écrit en Scala gratuit et open source, qui encourage
le développement rapide et propre. Play est un Framework web qui suit le patron de
conception « Design pattern » MVC (Model View Controller) où la couche de présentation
est divisée en une vue et une couche de contrôleur. La figure 5.1 illustre l’architecture
logicielle du Framework Play Scala.
Figure 5.1 – Architecture logicielle du Framework Play scala
Toutes les requêtes HTTP suivent le même chemin :
• Une requête HTTP est reçue par le Framework.
• Le composant "Route" tente de trouver la route la plus spécifique capable d’accepter
cette requête. La méthode d’action correspondante est ensuite invoquée.
• Le code de l’application est exécuté.
• Si une vue complexe doit être générée, un fichier modèle est rendu.
• Le résultat de la méthode d’action (code de réponse HTTP, contenu) est ensuite
écrit en tant que réponse HTTP.
5.1.2.2 JSON Web Token
Les JWT sont des jetons générés par un serveur lors de l’authentification d’un utilisa-
teur sur une application web, et qui sont ensuite transmis au client. Pourquoi JWT Dans
Rapport de Projet de Fin d’études 38
CHAPITRE 5. Réalisation
le cas d’une application où on consomme des API REST. Le transfert des données se fait à
travers des requêtes HTTP et sous format JSON. Et c’est comme ça que l’authentification
avec JWT fonctionne[10].
5.1.2.3 Test unitaires
En programmation, les tests unitaires constituent une procédure permettant de vérifier
le bon fonctionnement d’une partie précise d’un logiciel. Ils aident à trouver les erreurs
rapidement, à sécuriser la maintenance et réduire son coût et à documenter le code source.
Les tests unitaires et de composants constituent la base du développement
En effet, l’approche TDD permet de garantir la qualité du code et la fréquence des
évolutions s. Pour ce type de test, nous avons utilisé la librairie relative au Framework
Play qui s’appelle «ScalaTest». Pour les tests unitaires, en a fait un descriptif détaillé des
tests effectués pendant le stage est donné dans l’annexe C «Test unitaires».
5.1.2.4 Les pull-request
Un fork désigne une copie d’un dépôt. En effet, par défaut il n’est pas possible de faire
de commit sur un dépôt qui ne nous appartient pas. Du coup, les services ont introduit
cette notion de fork qui permet de se retrouver avec un dépôt sur le quelle on aura la
permission d’écriture. La notion de pull-request va de pair avec le système de Fork. Une
fois que l’on a travaillé sur notre fork on souhaite souvent proposer à l’auteur original
nos modifications. On fera alors un pull-request qui consiste tout simplement à demander
à l’auteur original de merge nos modifications. Ce processus est géré de manière quasi
automatique par GitHub et Bitbucket[11].
Pour les pull-request, monsieur Guillaume BADIN c’est la seule personne que peut
merge vos modifications.
La figure ci-dessus pressent un exemple d’un pull-request.
Rapport de Projet de Fin d’études 39
CHAPITRE 5. Réalisation
Figure 5.2 – Demande d’un pull-request
5.1.3 Mode de fonctionnement de l’application
Dans cette partie, nous allons présenter les principales fonctionnalités attendues de
l’API sous forme d’interfaces Web ou peut aussi sous forme d’interface mobile. Notre API
a été développer en partie "Back-End" et consommer par une application Web (partie
"Front-End") ou partie mobile en utilisant les Framework Angular 4.4.6 et Bootstrap
ou en utilisant ASP.net en partie mobile. Nous présentons par la suite les principales
interfaces de chaque mirco-sercice.
5.1.3.1 Identity
Pour Identity, on a choisi de décrire que le travail qu’on a réalisé pour les utilisateurs
et les groupes.
Groupe :
La figure 5.3 illustre l’interface qui présente la liste des groupes. Il dispose des fonc-
tionnalités qui suivent :
Rapport de Projet de Fin d’études 40
CHAPITRE 5. Réalisation
• Rechercher un groupe.
• Ajouter un nouveau groupe.
• Ajouter ou enlever des utilisateurs.
• Supprimer le groupe.
Figure 5.3 – La liste des groupes
Les Figures 5.4 et 5.5 présentent les informations du groupe et aussi les membres utilisa-
teurs appartient à ce groupe.
Figure 5.4 – Les informations du groupe
Rapport de Projet de Fin d’études 41
CHAPITRE 5. Réalisation
Figure 5.5 – Les membres du groupe
Utilisateur :
La ci-dessous présente l’interface qui présente la liste des utilisateurs. Il offre des
fonctionnalités qui suivent :
• Recherche un utilisateur.
• Filtrer les utilisateurs par des filtres dynamiques.
• Exporter les utilisateurs.
• Joindre l’utilisateur à un groupe.
• Mettre en pause l’utilisateur.
• Archiver l’utilisateur.
Rapport de Projet de Fin d’études 42
CHAPITRE 5. Réalisation
Figure 5.6 – Les membres du groupe
Les figures ci-dessous présente les 4 étapes qu’il faut faire pour créer un nouvel utilisateur.
Figure 5.7 – Étape 1/4 : Identité
Figure 5.8 – Étape 2/4 : informa-
tions complémentaires
Rapport de Projet de Fin d’études 43
CHAPITRE 5. Réalisation
Figure 5.9 – Étape 3/4 : informa-
tions de contact
Figure 5.10 – Étape 4/4 : mot de
passe
5.1.3.2 Laboratory
À ce stade, nous allons choisir quelque capture d’écrans concrète qu’on réaliser dans
le projet Laboratory :
Configuration Général :
La figure 5.11 illustre l’interface de modification de logo et favicon : le logo se trouve
dans les étapes d’identification ou dans l’entête du menu des paramètres et le favicons est
utilisé comme icône dans la barre d’adresse, dans les onglets et dans les favoris de votre
navigateur.
Rapport de Projet de Fin d’études 44
CHAPITRE 5. Réalisation
Figure 5.11 – Personnaliser Ubilab
Nous présentons dans la figure 5.12 le page permet de définir le type de connexion à
logiciel Ubilab sachant que la traçabilité sur les modifications apportées à Ubilab n’est
pas appliquée que sur les personnes se connectant avec un compte.
Rapport de Projet de Fin d’études 45
CHAPITRE 5. Réalisation
Figure 5.12 – Connexion à Ubilab
La figure 5.13 illustre présente la page qui permet d’activer le mail récapitulatif et
aussi ajouter des mails récapitulatifs pour conserver une trace de ces modifications des
examens partagés.
Configuration examens :
La figure 5.14 illustre présente la page qui permet d’activer le mail récapitulatif et
aussi ajouter des mails récapitulatifs pour conserver une trace de ces modifications des
examens partagés.
Rapport de Projet de Fin d’études 46
CHAPITRE 5. Réalisation
Figure 5.13 – Gestion du notification
La ci-dessous présente l’interface qui permet de choisir mode affichage de prélèvement.
Figure 5.14 – Mode de prélèvements
Nous présentons dans la figure 5.15 le page que nous pouvions indiquer nouvelle numéro
de version des examens.
Rapport de Projet de Fin d’études 47
CHAPITRE 5. Réalisation
Figure 5.15 – List du catalogue d’examens
Configuration manuel :
L’administrateur peut aussi consulter la liste des catégories des fichiers et ajouter
une nouvelle catégorie ainsi peut le supprimer si ce dernier n’est pas attaché à des fiches
comme montre le figure 5.16, 5.17 et 5.18.
Figure 5.16 – List des catégories
Rapport de Projet de Fin d’études 48
CHAPITRE 5. Réalisation
Figure 5.17 – Ajout d’une catégo-
rie
Figure 5.18 – Suppression d’une
catégorie
Communication :
La figure 5.19 illustre présente l’interface qui permet de personnaliser le mail d’envoi
des d’identifiant par choisir le contenu du mail ainsi que l’objet ou même par ajouter une
adresse mail d’envoie en copie cachée.
Figure 5.19 – Liste des catégories
Rapport de Projet de Fin d’études 49
CHAPITRE 5. Réalisation
La ci-dessous présente l’interface qui permet d’activer les notifications de rappel, choi-
sir une délai de la période d’inactivité en jours et choisir la préférence d’envoi : SMS
uniquement, Moi uniquement, etc. Ces notifications de rappel sont envoyées à toutes les
IDE qui ne sont pas connectées à "Ubilab" pendant une certaine piéride.
Figure 5.20 – Rappels automatiques
Configuration application
La figure 5.20 présente la page qui permet de modifier l’image d’accueil, cette image
se trouve dans la page d’accueil d’application. Elle permet une meilleure personnalisation
et un environnement plus familier pour les utilisateurs.
Figure 5.21 – Image accueil application
Rapport de Projet de Fin d’études 50
CHAPITRE 5. Réalisation
La ci-dessous présente l’interface qui permet à l’administrateur de modifier le mot
du labo : c’est le texte qui apparaît dans la partie « Contacter le laboratoire » dans les
paramètres de l’application mobile.
Figure 5.22 – le mot du labo
5.1.3.3 Talk
A l’aide des captures d’écran nous Allons ici décrire notre travail réalise pour le projet
Talk ce travail devise en deux parties : Web et mobile.
Web :
La figure 5.15 représente l’interface principale pour Talk version web.
Rapport de Projet de Fin d’études 51
CHAPITRE 5. Réalisation
Figure 5.23 – Interface principale pour Talk version web
À gauche, nous proposons un menu "sidebar" de navigation comportant la liste de
chaînes : publique comme Général, Random et les chaînes Direct.
En haut, nous trouvons le nombre de participants dans la chaîne et le date de dernier
message envoyer dans la chaîne.
Au milieu nous présentons la liste de messages et chaque message contient le nom
d’utilisateur ainsi que le date d’envoi du message et les réactions.
À droite, la liste de participants et aussi les fichiers partages dans cette chaîne et un
"checkbox" qui permet de Désactiver les notifications.
Mobile :
Les figures illustres l’interface Talk dans application mobile. Ils présentent le page chat
dans les cas suivent :
• S’il n’y a pas des messages.
• Si le message a été envoyé.
• Si le message n’a pas été envoyé dans ce cas Talk vous offre la possibilité de réessayer
d’envoyer un message.
Rapport de Projet de Fin d’études 52
CHAPITRE 5. Réalisation
• Si un quelqu’un est en train d’écrire.
Figure 5.24 – Page chat dans le cas
il n’y a pas des messages
Figure 5.25 – Indiquer l’état d’un
message envoyé
Rapport de Projet de Fin d’études 53
CHAPITRE 5. Réalisation
Figure 5.26 – Cas réessayer d’en-
voyer un message
Figure 5.27 – Interface pour un
message non envoyé et si un utili-
sateur en train d’écrire
Conclusion
À travers ce dernier chapitre, nous avions commencé par décrier l’environnement lo-
giciel et ensembles des technologies que nous avons utilisées. Puis, nous avons présenté
une description des fonctionnalités principales de chaque micro-service en utilisant des
captures d’écrans.
Rapport de Projet de Fin d’études 54
Conclusion
Le présent rapport illustre le travail des six mois établis en vue d’obtention du diplôme
national d’ingénieur en télécommunication à Silk. Durant ce stage, nous sommes arrivés
à construire une solution micro-services d’ensembles fonctionnalité déployer par Silk qui
offre :
• La distribution de tous les traitements des données.
• L’optimisation des ressources consacrées aux application.
• La facilité de détection d’erreurs.
Nous sommes arrivés intègres un nouveau projet POC "Talk". Ce dernier permet aux
clients de Silk d’échanger par des messages instantanés en temps réels avec utilisateurs
concernant : les actualités, les non conformités, les rappels de mises à jour, etc.
En utilisant la méthode agile Scrum, sur le plan méthodologique qui nous a permis
de réaliser les ensembles des objectifs mis en place au début du stage en respectant la
planification initiale et le date limite associes à chaque tâche.
Sur le plan technique, nous avons développé nos connaissances dans le domaine de
développement informatique pour renforcer mon intérêt pour le domaine télécommunica-
tion.
Néanmoins, il existe d’autres améliorations qui peuvent être implémentées pour :
• Optimiser la communication entre les micro-services.
• Ajouter des nouvelles fonctionnalités dans le projet Identity et Laboratory comme
intégrer les ensembles d’actions faite par les utilisateurs dans projet Ubilab-Result
et Ubilab-Visi dans le système archivages.
• Avoir des discussions communes entre différentes laboratoires dans la région France
entière.
55
Références
[1] “Les applications mobile au service du corps médical,” https://blog.axopen.com/
2018/02/application-mobile-sante-hopital/, dernière Consultation : 30/08/2018.
[2] “Ubilab,” http://ubilab.io/, dernière Consultation : 26/08/2018.
[3] X. L. A. J. G. A Stellman, Understanding Scrum. O’Reilly Media, 2014. (Cité en
page 4.).
[4] “Documentation micro-service,” ://www.lemagit.fr/tribune/Microservices-avantages-
et-inconvenients-de-la-nouvelle-structure-de-serveurs-web.
[5] “Jetbrains documentation,” https://www.jetbrains.com/idea/documentation/, der-
nière Consultation : 2018-08-15.
[6] “Gestionnaire de version décentralisé,” https://www.projet-plume.org/fiche/git, der-
nière Consultation : 2018-09-07.
[7] “Git documentation,” http://doc.ubuntu-fr.org/git, dernière Consultation : 2018-08-
15.
[8] “Postico documentation,” https://eggerapps.at/postico/l, dernière Consultation :
2018-08-18.
[9] “Postgresql documentation,” https://www.commentcamarche.com/contents/
814-postgresql-introduction, dernière Consultation : 2018-08-18.
[10] E. Alpaydın, “Json documentation,” https://jwt.io/introduction/, dernière Consul-
tation : 2018-05-18.
[11] “Pull-request documentation,” https://www.grafikart.fr/formations/git/
fork-pull-request, dernière Consultation : 2018-05-18.
56
CHAPITRE 5. Réalisation
[12] “Services web ou api,” http://www.christian-faure.net/2012/10/08/
services-web-ou-api/, dernière Consultation : 2018-08-30.
[13] “Api rest,” https://www.supinfo.com/articles/single/
5642-qu-est-ce-qu-une-api-rest-restful, dernière Consultation : 2018-05-15.
[14] “Web socket,” https://jmdoudoux.developpez.com/cours/developpons/java/
chap-websockets.php, dernière Consultation : 2018-08-28.
[15] “Rabbitmq,” https://blog.eleven-labs.com/fr/rabbitmq-partie-1-les-bases/, note =
Dernière Consultation : 2018-08-8.
[16] “Documentation rabbitmq,” http://www.rabbitmq.com/documentation.html, der-
nière Consultation : 2018-08-28.
[17] “Actor akka,” https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html#
Introduction, dernière Consultation : 2018-08-28.
Rapport de Projet de Fin d’études 57
Annexes
58
Annexe A
WebService Rest APIS
et
WEBSERVICE APIS
Dans cette annexe, nous avons comprendre les classifications les déférents API’s. En
matière de communication Web, nous pouvons identifier deux types d’API significatifs :
les API de service Web (par exemple, SOAP, JSON-RPC, XML-RPC, REST) et les API
Websocket.
WebService
Un service web est un protocole d’interface informatique de la famille des
technologies web permettant la communication et l’échange des données entre
applications et systèmes échange des données entre applications et systèmes
hétérogènes [12].
La communication est toujours localisée dans le cadre d’un protocole de
la couche application. WebService utilise HTTP comme une protocole de
communication.
Le protocole HTTP
C’est un protocole de communication client-serveur. Les requêtes HTTP
effectuent sur le serveur disposent d’une méthode qui est une commande qui
a pour rôle de spécifier l’action qu’on veut exécuter sur les ressources du
serveur.
API REST
Une API REST peut être modélisée comme une boite noire qui contient
des fonctions chacune nous permet de gérer des ressources sur le serveur.
Chaque fonction est distinguée par une route et une méthode HTTP. Ainsi,
pour accéder au service d’une fonction on envoie une requête HTTP avec sa
méthode et sur sa route [13].
Exemples Le tableau suivant présente un exemple d’API de gestion d’un
groupe.
Rapport de Projet de Fin d’études 1
Annexe A
Table 1 – Exemple d’une API REST (Méthodes HTTP, routes et descriptions)
Méthode
HTTP
Route Description Type de
l’opération
GET /group/list Récupérer la liste des
groupes
Lecture seule
GET /group/info/1 Récupérer les infor-
mations relatives au
groupe ayant l’ID 1
Lecture seule
POST /group/create Ajouter un nouveau
groupe
Ecriture
PUT /group/update/1 Mise à jour le groupe
qui possède l’identi-
fiant 1
Ecriture
DELLETE /goup/1/delete Supprimer le client
dont l’identifiant est
égal à 1
Ecriture
Exemple :
La figure ci-dessus présente un exemple d’une requête GET et réponse du
serveur en utilisant Postman.
Figure A1 – Exemple d’une requête GET et réponse du serveur
WebSocket :
Une WebSocket permet l’échange données entre un client et un serveur
de manière asynchrone, bidirectionnelle en mode full duplex utilisant une
Rapport de Projet de Fin d’études 2
Annexe A
connexion TCP. Les WebSockets sont typiquement utilisées pour envoyer de
petits messages. La spécification du protocole WebSocket est définie dans la
RFC 6455, publiée en décembre 2011.
Les WebSockets sont plus efficaces et sont plus performantes que les autres
solutions :
• Elles requièrent moins de bande passante car elles ne requièrent pas
d’en-tête dans chaque message.
• La latence est réduite.
• Elles permettent de mettre en place des solutions quasi temps réel pour
recevoir des données.
Les cas d’utilisation des WebSockets sont nombreux : elles sont utilisables
dès que des données doivent être envoyées du serveur vers le ou les clients[14].
Rapport de Projet de Fin d’études 3
Annexe B
RabbitMQ
RabbitMQ est un message broker très complet et robuste, son rôle est de
transporter et router ensembles des messages à partir de les Publishers vers
les Consumers. Ce broker utiliser les exchanges et bindings pour connaitre
s’il doit délivrer, ou non le message dans la queue.
Fonctionnalité du broker :
Voici comment le broker se fonctionne :
Dans un exchange, le Publisher va envoyer un message, l’exchange va, en fonc-
tion du binding, router le message vers la ou les queues. Enfin, un Consumer
va consommer les messages [15]. Comme, présente la figure ci-dessus.
Figure B1 – Architecture de système rabbitMQ
Dans ce stade, nous allons donc détailler les éléments qui composent le
broker.
• Le message :
Le message est comme une requête HTTP, il contient des attributs et
un payload. Parmi les attributs du que vous pouvez ajouter sont les
headers.
• Les Bindings :
Rapport de Projet de Fin d’études 4
Annexe B
Les bindings, ce sont les règles que les exchanges utilisent pour détermi-
ner à quelle queue il faut délivrer le message. Les différentes configura-
tions peuvent utiliser la routing key (direct/topic exchanges) ainsi que
les headers (header exchanges). Dans le cas des exchanges “fanout”, les
queues n’ont qu’à être blindées pour recevoir le message [15].
• Les exchanges :
Un exchange est un routeur de message. Il existe plusieurs types de
routages, dans le cas de broker rabbitMQ sont définis comme un type
d’exchange :
– L’exchange fanout : C’est le plus simple. Il délivre le message à
toutes les queues bindées comme explique le schéma ci-dessous.
Figure B2 – Schéma éxhange de type fanout
– L’exchange direct : L’exchange direct utilise la routing_key pour
autoriser le binding donc Si la routing_key du message est égale à
la routing_key indiquée dans le binding alors le message sera délivré
à cette queue.
Le figure ci-dessous présente le principe d’exchange direct :
Rapport de Projet de Fin d’études 5
Annexe B
Figure B3 – Schéma éxhange de type fanout
• Les Queues :
Une queue est l’endroit où sont stockés les messages. Il existe des options
de configuration afin de modifier leurs comportements.
Quelques options :
– Durable, (stockée sur disque) la queue survivra au redémarrage du
broker. Attention seuls les messages persistants survivront au redé-
marrage.
– Exclusive, sera utilisable sur une seule connexion et sera suppri-
mée à la clôture de celle-ci. Auto-delete, la queue sera suppri-
mée quand toutes les connexions sont fermées (après au moins une
connexion)[15].
• Consumer : Le rôle du consumer est d’exécuter un traitement après
avoir récupéré un ou plusieurs messages.
Pour ce faire il va réserver (prefetching) un ou plusieurs messages depuis
la queue, avant d’exécuter un traitement. Généralement si le traitement
s’est correctement déroulé le consumer va acquitter le message avec suc-
Rapport de Projet de Fin d’études 6
Annexe B
cès (basic.ack). En cas d’erreur le consumer peut également acquitter
négativement le message (basic.nack). Si le message n’est pas acquitté,
il restera à sa place dans la queue et sera re fetch un peu plus tard [16].
Rapport de Projet de Fin d’études 7
Annexe C
Tests Unitaires
Pour cette partie, nous avons effectué des tests unitaires sur l’API REST
ou WebSocket de l’application de quelques micro-services que nous avons
développé aux cours de stage, afin d’assurer une application robuste et main-
tenable. Pour faire les tests unitaires, nous utilisions une librairie nommée
"ScalaTest".
Nous allons vous décrirez quelques scénarios de test qui nous avons réalisé.
Pour chaque test réalisé nous avons créé une fonction qui s’appelé "onI-
nit()"et une fonction «clearDataBase».
• La fonction "onInit()" est invoqué avant chaque méthode de test, elle se
charge d’initialiser la mémoire de test, créer des instance d’objet, insérer
des élément dans les collections, etc.
• La fonction "clearDatabase()" est appelée après chaque méthode de test,
elle supprime tout instance d’objet, vider tous les collection, etc.
Figure C1 – Fonction onInit() et clearDatabase()
La figure 7.14 illustre un exemple de la méthode "onInit()" et "clear-
Database()" pour le teste des avis relative à chaque micro-service. Lors de
lancement de test la méthode "onInit()" appelé les méthodes "createRoom",
Rapport de Projet de Fin d’études 8
Annexe C
"creatRoomSupport" et "saveListMessage" que ils permettent de charger le
mémoire par information à propos le Room et les messages .À la fin de test la
méthode "clearDatabase()" supprime tous les information que été enregistrer
dans la mémoire.
Tester l’endpoint «sérialisation et désérialisations d’objet JSON»
La figure ci-dessous décrit le test réalisé pour sérialiser et désérialiser un objet
JSON.
Figure C2 – Sérialiser et désérialiser un objet JSON
Ce test consiste à :
1- Vérifier si lorsqu’en transférions objet "messageWs1" à objet JSON doit
être égale à celui "messageExpectedJson". Ce dernier décrit le vrais
format JSON que l’objet messageWS1 doit vérifier.
Rapport de Projet de Fin d’études 9
Annexe C
2- Vérifier que si en recevons un objet JSON "messageExpectedJson" et
en applique désérialisation doit être égale à notre objet "messageWs1".
Tester l’endpoint «MakeUniqueInternalMail
La figure C3 illustre le test réalisé sur la méthode "makeUniqueInternal-
Mail".
Figure C3 – Fonction MakeUniqueInternalMail
Ce test consiste à réaliser une opération de création MailIn associe à un
groupe :
1- Réaliser méthode qui permet de encapsuler le nom de groupe avec le
nom de domaine "ubilab.me".
2- Vérifier que le MailIn créé est unique.
Tester l’endpoint «envoie et réception des message avec les Actor
de AKKA»
Rapport de Projet de Fin d’études 10
Annexe C
Akka est un Framework pour la construction de systèmes distribués ba-
sés sur les acteurs. La philosophie adoptée en termes de tolérance de panne
pour ces systèmes est « let it crash». En effet, les acteurs sont des éléments
légers, qu’il est facile d’instancier et de relancer en cas de crash (du fait qu’ils
ne partagent pas leur état). Pour cela, Akka impose une supervision afin de
pouvoir gérer la mort prématurée d’acteurs, et ce dans une hiérarchie de su-
pervision : tout nouvel acteur est supervisé par son parent. Cette supervision
permet la création de systèmes qui s’auto-réparent[17].
La figure ci-dessous décrit le test réalisé pour faire envoie et réception des
message avec les Actors de AKKA.
Figure C4 – Envoie et réception des message avec les Actors
Ce test consiste à :
1- Créer un message de type WsMobileIIn et s’appelle "mobileInMsg1" ce
message contient les informations nécessaires pour créer une nouvelle
Rapport de Projet de Fin d’études 11
Annexe C
chaîne de discussions.
2- Créer un Actor "wsAcorService" qui permet d’envoyer et réceptionner
le message "mobileInMsg1".
3- Vérifier que notre mémoire contient la nouvelle chaîne de discussions.
Rapport de Projet de Fin d’études 12
Annexe C
Rapport de Projet de Fin d’études 13

Contenu connexe

Tendances

Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileRim ENNOUR
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Nawres Farhat
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaNazih Heni
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachAyoub Mkharbach
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSFaissoilMkavavo
 
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...tayebbousfiha1
 
Rapport stage pfe
Rapport stage  pfe Rapport stage  pfe
Rapport stage pfe rimeh moussi
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Mohamed Aziz Chetoui
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatiqueHicham Ben
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webSalma Gouia
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementNassim Bahri
 
Rapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIARapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIAAhmed BEN JEMIA
 
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)safwenbenfredj
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile Raoua Bennasr
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEOussama Djerba
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRouâa Ben Hammouda
 
Rapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelRapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelBelwafi Bilel
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITLina Meddeb
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux fehmi arbi
 
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...MOHAMMED MOURADI
 

Tendances (20)

Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application Mobile
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...
 
Rapport stage pfe
Rapport stage  pfe Rapport stage  pfe
Rapport stage pfe
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Rapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIARapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIA
 
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
Rapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelRapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilel
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
 
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...
 

Similaire à Rapport de projet de fin d"études

Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Adem Amen Allah Thabti
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsUniversité de Rennes 1
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...mouafekmazia
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Yasmine Lachheb
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testahmed oumezzine
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaIlef Ben Slima
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifsSafaAballagh
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Houssem Eddine Jebri
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Mohamed Boubaya
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD) Ben Ahmed Zohra
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développementGlei Hadji
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesBenjamin Vidal
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueYosra ADDALI
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesHosni Mansour
 

Similaire à Rapport de projet de fin d"études (20)

Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
 
Deploy automatic in the cloud
Deploy automatic in the cloudDeploy automatic in the cloud
Deploy automatic in the cloud
 
siem.pdf
siem.pdfsiem.pdf
siem.pdf
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
 
iRecruite
iRecruiteiRecruite
iRecruite
 

Rapport de projet de fin d"études

  • 1. République Tunisienne Ministère de l’Enseignement Supérieur et de la Recherche Scientifique Université de Tunis El Manar École Nationale d’Ingénieurs de Tunis DÉPARTEMENT TIC Projet de fin d’études Présenté par Mohamed BOUBAYA Pour l’obtention du Diplôme National d’Ingénieur en Télécommunications Refonte et déploiement des modules en utilisant l’architecture micro-services Réalisé à Soutenu le 26/09/2018 Devant le Jury : Président : M. Taoufik AGUILI Rapporteur : Mme Monia TURKI Encadrant Organisme d’accueil : M. Guillaume BADIN Encadrant ENIT : M. Taher EZZEDINE Année universitaire 2017/2018
  • 2. Signatures Superviseur Silk : M. Guillaume BADIN Superviseur ENIT : M. Tahar EZZEDINE i
  • 3. Dédicace À mes chers parents qu’aucune mot ne pourrais exprimer ma gratitude et mon amour, que ce travail soit le couronnement de votre implication, vos efforts, vos sacrifices et votre dévouement absolu. À mon frère et mes soeurs, que le bonheur, la réussite et la prospérité bénissent vos chemins. Aux membres de ma famille, pour vos encouragements continu votre soutien. À mes amis pour votre orientation, votre affection et votre présence. À toute personne qui a croisé mon chemin. Je tiens à vous dédier cet travail. ii
  • 4. Remerciements Au terme de ce travail, J’ai un plaisir de réserver ces quelques lignes de gratitude à tous ceux et celles qui, de près ou de loin, ont contribué à la réalisation et l’aboutissement de ce travail. Mes remerciements s’adressent particulièrement à : • M. Christophe DUBERNET DE BOSCQ, directeur Général de Silk, pour m’avoir prodigué l’honneur de travailler dans son équipe. • M. Guillaume BADIN, chief projet et mon encadrant de stage qui a proposé et suivi ce travail. Je lui exprime toute ma profonde de reconnaissance pour la confiance et son aide qu’il m’a apporté long toutes les phases de ce stage. Ses conseils, sa disponibilité, son encadrement et m’ont été précieux qu’il m’a prodigués autant pour atteindre les objectifs. • M. Taher EZZEDINE, maître de conférences à l’École Nationale d’Ingénieurs de Tunis, pour son soutien et sa rigueur pour la qualité de son enseignement et ses conseils sans oublier sa participation au cheminement de ce rapport. • A mes amis à Silk et spécialement Rémi KOWALSKI, Florian GALLE, Lounès BADJI, Hubert RAYNAUD et Benjamin BONNETTO pour leur aide et leurs pro- positions long de ce stage. • Mon dernier mot s’adresse à tous les membres de l’honorable jury que je remercie d’avoir accepté d’examiner ce modeste travail. iii
  • 5. Résumé Projet s’inscrit dans le cadre d’un projet de fin d’études au sein de l’entreprise Silk France pour une durée de six mois. Dans un environnement Agile, la société m’a confié la mission de développer des plusieurs modules : un module pour la gestion du laboratoire un autre pour la gestion du personnel de laboratoire et un module POC permet d’envoyer des messages instantanés en temps réel, réagir à un message et partager des fichiers. Mots clés : Scala, Play2.6, RabbitMQ,API REST, API WebSocket. Abstract Project is part of a graduation project within the company Silk France for a period of six months. In an Agile environment, the company entrusted me with the mission of developing several modules : a module for the management of the laboratory another for the management of the laboratory staff and a POC module makes it possible to send instant messages in real time, react to a message and share files. Key Words : Scala, Play2.6, RabbitMQ,API REST, API WebSocket. iv
  • 6. Table des matières Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Liste des tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Liste des acronymes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Introduction Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 Cadre du projet 2 1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 3 1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . 4 1.4.1 Avantages de la méthode agile Scrum . . . . . . . . . . . . . . . . 5 1.4.2 Environnements mis en place . . . . . . . . . . . . . . . . . . . . . 5 1.4.3 L’ensemble des acteurs de projet . . . . . . . . . . . . . . . . . . . 6 2 Architecture Micro-service 8 2.1 Architecture micro-service . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.1 Les Avantages de l’architecture des micro-services . . . . . . . . . . 10 2.1.2 Les inconvénients de l’architecture des micro-services . . . . . . . . 10 2.1.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3 Analyse et spécification des besoins 14 3.1 Définition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.1 Les acteurs projet Identity . . . . . . . . . . . . . . . . . . . . . . . 15 v
  • 7. 3.1.1.1 Les acteurs projet Laboratory . . . . . . . . . . . . . . . 15 3.1.1.2 Les acteurs projet Talk . . . . . . . . . . . . . . . . . . . 16 3.2 Expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1.1 Projet Identity . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1.2 Projet Laboratory . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1.3 Projet Talk . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.2 Besoins non fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3 Vue globale du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3.1 Vue globale du projet Talk . . . . . . . . . . . . . . . . . . . . . . 18 3.4 Raffinement des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 20 3.4.1 Raffinement des cas d’utilisation du projet Identity . . . . . . . . . 20 3.4.2 Raffinement des cas d’utilisation du projet Laboratory . . . . . . . 22 4 Conception de notre solution 25 4.1 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2.1 Projet Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2.1.1 Diagramme de class . . . . . . . . . . . . . . . . . . . . . 27 4.2.1.2 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . 28 4.2.2 Projet Laboratory . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2.2.1 Diagramme de class . . . . . . . . . . . . . . . . . . . . . 29 4.2.2.2 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . 30 4.2.3 Projet Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.3.1 Diagramme de class . . . . . . . . . . . . . . . . . . . . . 30 4.2.3.2 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . 32 4.3 Diagrammes séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5 Réalisation 35 5.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 vi
  • 8. 5.1.1 Environnement Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1.1.1 Intellij IDEA Community Edtion . . . . . . . . . . . . . . 36 5.1.1.2 GIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1.1.3 Postico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.1.4 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.1.5 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.2.1 Framework Play Scala . . . . . . . . . . . . . . . . . . . . 38 5.1.2.2 JSON Web Token . . . . . . . . . . . . . . . . . . . . . . 38 5.1.2.3 Test unitaires . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.1.2.4 Les pull-request . . . . . . . . . . . . . . . . . . . . . . . . 39 5.1.3 Mode de fonctionnement de l’application . . . . . . . . . . . . . . . 40 5.1.3.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.1.3.2 Laboratory . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.1.3.3 Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Références 56 Annexes 58 vii
  • 9. Table des figures 1.1 Dashboard de la méthodologie adopté au sien de la société . . . . . . . . . 6 2.1 Architecture micro-services et architecture monolithique . . . . . . . . . . 9 2.2 Ancient architecture monolithique d’Ubilab . . . . . . . . . . . . . . . . . . 11 2.3 Nouvelle architecture d’Ubilab . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1 Diagramme de cas d’utilisation globale du projet Talk . . . . . . . . . . . . 19 3.2 Digramme de cas d’utilisation de la rubrique administration pour le projet Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Digramme de rubrique administration pour le projet Laboratory . . . . . . 23 4.1 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2 Diagramme de classe de la couche modelé de projet Identity . . . . . . . . 28 4.3 Diagramme de classe de la couche modelé de projet Laboratory . . . . . . 29 4.4 Diagramme de classe de la couche modelé de projet Talk . . . . . . . . . . 31 4.5 Diagramme de séquence de création d’un groupe . . . . . . . . . . . . . . . 33 5.1 Architecture logicielle du Framework Play scala . . . . . . . . . . . . . . . 38 5.2 Demande d’un pull-request . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3 La liste des groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.4 Les informations du groupe . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.5 Les membres du groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.6 Les membres du groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 viii
  • 10. 5.7 Étape 1/4 : Identité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.8 Étape 2/4 : informations complémentaires . . . . . . . . . . . . . . . . . . 43 5.9 Étape 3/4 : informations de contact . . . . . . . . . . . . . . . . . . . . . . 44 5.10 Étape 4/4 : mot de passe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.11 Personnaliser Ubilab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.12 Connexion à Ubilab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.13 Gestion du notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.14 Mode de prélèvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.15 List du catalogue d’examens . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.16 List des catégories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.17 Ajout d’une catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.18 Suppression d’une catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.19 Liste des catégories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.20 Rappels automatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.21 Image accueil application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.22 le mot du labo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.23 Interface principale pour Talk version web . . . . . . . . . . . . . . . . . . 52 5.24 Page chat dans le cas il n’y a pas des messages . . . . . . . . . . . . . . . . 53 5.25 Indiquer l’état d’un message envoyé . . . . . . . . . . . . . . . . . . . . . . 53 5.26 Cas réessayer d’envoyer un message . . . . . . . . . . . . . . . . . . . . . . 54 5.27 Interface pour un message non envoyé et si un utilisateur en train d’écrire . 54 A1 Exemple d’une requête GET et réponse du serveur . . . . . . . . . . . . . 2 B1 Architecture de système rabbitMQ . . . . . . . . . . . . . . . . . . . . . . 4 B2 Schéma éxhange de type fanout . . . . . . . . . . . . . . . . . . . . . . . . 5 B3 Schéma éxhange de type fanout . . . . . . . . . . . . . . . . . . . . . . . . 6 C1 Fonction onInit() et clearDatabase() . . . . . . . . . . . . . . . . . . . . . 8 C2 Sérialiser et désérialiser un objet JSON . . . . . . . . . . . . . . . . . . . . 9 C3 Fonction MakeUniqueInternalMail . . . . . . . . . . . . . . . . . . . . . . . 10 C4 Envoie et réception des message avec les Actors . . . . . . . . . . . . . . . 11 ix
  • 11. Liste des tableaux 1.1 Acteurs et missions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Description scénariste du cas d’utilisation « Afficher les informations d’un message» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Description scénariste du cas d’utilisation « Créer un utilisateur » . . . . . 22 3.3 Description scénariste du cas d’utilisation « Modifier logo de laboratoire » 24 1 Exemple d’une API REST (Méthodes HTTP, routes et descriptions) . . . . 2 x
  • 12. Glossaire des acronymes POC : Proof of concept - une preuve de la faisabilité. SSH : Secure Shell. SSL : Transport Layer Security. API : Application Programmable Interface. SGBDR : Système de Gestion de Base de Données Relationnelle IDE : Integrated Development Environment. TDD : Test Driven Development. JWT : JSON Web Token. HTTP : Hypertext Transfer Protocol . REST : Representational State Transfe. SMS : Short Message Service. UML : Unified Modeling Language. JSON : JavaScript Object Notation. SVN : Subversion XML : Extensible Markup Language DAO : Data Access Object URL : Uniform Resource Locator TCP : Transmission Control Protocol xi
  • 13. Introduction Générale La santé, c’est avant tout un secteur où l’humain, le patient, est au cœur de toutes les considérations. Qui dit humain et santé dit relations humaines, et celles-ci sont d’autant plus délicates que le contexte, si particulier, est bien souvent de mauvais augure. Médecin, chirurgien, infirmière... autant de professions qui ne cessent de susciter des vocations chaque jour, avec un seul et même but en ligne de mire : aider les patients et prendre soin d’eux. Ainsi, en numérisant et en automatisant un certain nombre d’infor- mations et de tâches, on décharge le personnel de santé de préoccupations évidentes[1]. C’est dans ce cadre que la société Silk cherche aujourd’hui à développer leurs produits dédiés au pré-analytique en laboratoire et notamment aux manuels de prélèvements, dans le domaine de santé et de la biologie médicale. Dans le même contexte et pour améliorer l’expérience utilisateur, Silk pense à offrir à ses clients un module du tchat s’appelle Talk ainsi regrouper les fonctionnalités d’Ubilab en deux mirco-services. En effet, Le présent rapport décrire les étapes de la mise en œuvre du projet et les notions de base. Il est divisé en 5 chapitres. Le premier sera dédié au contexte général du stage. Dans le second chapitre nous allons faire une étude sur architecture micro-service dont nous expliquons architecture utiliser au cours de stage. Nous consacrons le troisième chapitre à l’analyse des besoins fonctionnels et non fonctionnels de la solution avec une spécification détaillée à l’aide des diagrammes UML (Unified Modeling Language). Dans le quatrième chapitre, comporte la description l’architecture logicielle de notre solution ainsi que la conception détaillée. Le dernier chapitre de présente l’environnement de travail et les outils utilisés pour la réalisation de l’API(WebSocket, HTTP) ainsi qu’une présenta- tion des fonctionnalités de l’application réalisée. Ce rapport s’achève par une conclusion générale et les perspectives futures de ce travail. 1
  • 14. Chapitre 1 Cadre du projet Plan 1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . 3 1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Méthodologie de développement . . . . . . . . . . . . . . . . . 4 1.4.1 Avantages de la méthode agile Scrum . . . . . . . . . . . . . . 5 1.4.2 Environnements mis en place . . . . . . . . . . . . . . . . . . . 5 1.4.3 L’ensemble des acteurs de projet . . . . . . . . . . . . . . . . . 6 2
  • 15. CHAPITRE 1.Cadre du projet Introduction Dans ce présent chapitre nous présentons l’entreprise Silk, puis nous posons le contexte et la problématique du projet pour enfin présenter la méthodologie de travail. 1.1 Présentation de l’organisme d’accueil Cofondée en 2011 par Guillaume BADIN et Christophe DUBERNET DE BOSCQ, amie depuis vingt ans qui sont passionnés par l’entrepreneuriat. Silk s’est d’abord spécia- lisée dans le développement BtoB de sites Internet et d’applications mobiles, et en 2013, Silk a lancé le travail sur un produit qui s’appelle Ubilab pour aider les laboratoires d’ana- lyses médicales. Toujours à la pointe de technologie, Silk permet aujourd’hui aux gens de laboratoire de gérer facilement et rapidement les informations pré-analytiques auprès des professionnels de santé internes ou externes au leur laboratoire associe à plusieurs services : • Ubilab-Home : vous permet de gérer votre référentiel d’examens, votre manuel de prélèvement et vos conventions de manière dématérialisée. • Ubilab-Learning : vous aide dans la formation de vos collaborateurs. Vous pouvez créer vos propres formations, importer vos formations existantes ou piocher dans le cata- logue. Vous pourrez délivrer des attestations, des habilitations et effectuer vos suivis de compétences. • Ubilab-Result : utilise notre infrastructure serveur dont l’hébergeur est agréé par l’ASIP Santé. Cela nous permet d’envoyer les résultats d’examen (ex : INR) aux profes- sionnels de santé via nos applications mobiles (notification push) en vous affranchissant des SMS non sécurisés. • Ubilab-Visit : accompagne les IDE lors de leurs tournées. Les IDE peuvent scanner tous types de documents (ordonnance, carte vitale, carte de mutuelle, carte d’identité, attestation de sécurité sociale, etc.) et les envoyer au laboratoire depuis le domicile du patient [2]. 1.2 Problématique Depuis le début, Silk a su que biologie médicale étant l’un de grand oubliés du vi- rage numérique. C’est pour ça, il a souhaité proposer une approche stratégique dans les logiciels médical. Pendant quel mois, en France Silk a pris une part prépondérante sur les services dédié aux professionnels de santé avec plus de 1600 laboratoires équipés. Le Rapport de Projet de Fin d’études 3
  • 16. CHAPITRE 1.Cadre du projet nombre des utilisateurs de produit "Ubilab" augmente chaque année de manière exponen- tielle. Chaque laboratoire à ses propres utilisateurs que ce soit biologiste, administrateur, infirmier, patient, etc. Effectivement, comme toute autre start-up ces fonctionnalités doivent correspondre et satisfaire aux l’ensembles besoins et demandes de ses clients pouvoir garantir les conti- nuations de leurs abonnements. D’autre part, concernent au nombre des utilisateurs qui augmente chaque jour et par rapport à la relation entre certain profile il y’a toujours pas un moyen de communication interne dans “Ubilab” ce qui empêche de se contacter directement dans application mobile ou même dans l’application web et qui les provoqué à se déplacer sur place pas mal des fois pour communiquer. Pour faire face à ces problèmes, la société Silk cherche aujourd’hui à mettre en place un module de chat qui relient ces utilisateurs et permettent de communiquer en temps réel et ainsi que faire la refonte et amélioration ergonomique d’application “Ubilab”. 1.3 Objectifs La société Silk cherche aujourd’hui à mettre en place un module de chat ainsi qu’amé- liorer leur produit “Ubilab”. Les objectifs de ce projet sont donc de : • Répondre au besoin de certains clients. • Faire une application plus performante plus ergonomique avec plus de fonctionnalités dont le client a vraiment besoin. • Ajouter un module de tchat interne à l’application vis-à-vis des laboratoires. 1.4 Méthodologie de développement Dédiées à la gestion de projets informatiques, les méthodes agiles reposent sur une approche itérative et incrémentale qui s’adaptent parfaitement aux futurs besoins du client [3]. Les méthodes agiles dirigèrent vers intégrer le client dans la réalisation du projet afin d’avoir un produit de haute qualité dans à brève échéance. Rapport de Projet de Fin d’études 4
  • 17. CHAPITRE 1.Cadre du projet Il existe plusieurs méthodologies dans la famille comme la méthode RUP, la méthode XP, la méthode Scrum, etc. Pour la gestion de ses projet la société Silk utilise la méthode, car à ce jour la méthode agile est la méthode la plus pratiquer parmi toutes les méthodes agiles existantes. C’est une méthode agile principalement basée sur des itérations de courtes durées appelées Sprints. 1.4.1 Avantages de la méthode agile Scrum La méthode agile Scrum a plusieurs avantages comme : — Avoir une idée claire sur déférents étapes du projet : une vue d’ensemble sur l’évo- lution du projet du l’étape développement vers étape production. — Avoir une flexibilité totale du projet : le client peut avoir une flexibilité totale au niveau de la définition des priorités selon leur besoins. — Avoir la meilleure qualité : une évaluation périodique de l’avancement du projet et sa permet de garantir une meilleure qualité du produit. — Avoir une planification adaptée au votre besoin : une planification détaillée à court terme et à long terme. 1.4.2 Environnements mis en place Dans la société Silk, il y’a deux environnements distincts seront mis en place : • Environnement de développement : dans lequel travaux de développement se- ront conduits. • Environnement de production : dans lequel sera placée la version validée à la fin du sprint. Comme montre la figure ci-dessus : Rapport de Projet de Fin d’études 5
  • 18. CHAPITRE 1.Cadre du projet Figure 1.1 – Dashboard de la méthodologie adopté au sien de la société 1.4.3 L’ensemble des acteurs de projet Nous présentons le tableau ci-dessous l’ensemble des acteurs participants au dévelop- pement des différentes étapes du projet : Rapport de Projet de Fin d’études 6
  • 19. CHAPITRE 1.Cadre du projet Table 1.1 – Acteurs et missions Rôle Acteurs Mission Équipe Mohamed BOUBAYA - Étude et conception et mise en place les modules. - Conception et développement du backend de module tchat. Hubert RAYNAUD - Aide à la conception et le développement les modules. Lounès BADJI - Conception et développement de la couche présentation pour le partie web. Florian GALLE - Création des pages Web et les pages mo- biles. Benjamin BONNETTO - Conception et développement de la couche présentation pour le partie mobile. Scrum Master Guillaume BADIN - Assurer que les valeurs et les principe de Scrum sont bien respectés. Product Owner Christophe DUBERNET - Définition validation des fonctionnalités dé- veloppées. Conclusion Dans ce premier chapitre, nous avons présenté le contexte général du projet. Nous avons commencé, tout d’abord, par une présentation de l’entreprise d’accueil Silk, ensuite nous avons introduit le contexte et la problématique du projet, enfin, nous avons consa- cré la dernière pratique la méthodologie adoptée ainsi l’ensemble environnements mis en place. Rapport de Projet de Fin d’études 7
  • 20. Chapitre 2 Architecture Micro-service Plan 2.1 Architecture micro-service . . . . . . . . . . . . . . . . . . . . . 9 2.1.1 Les Avantages de l’architecture des micro-services . . . . . . . . 10 2.1.2 Les inconvénients de l’architecture des micro-services . . . . . . 10 2.1.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8
  • 21. CHAPITRE 2. Architecture Micro-service Introduction Ce chapitre serai devise en deux parties : la première dans lequel nous allons détailler la conception, les avantages et l’inconvénient de l’architecture micro-service. Dans second partie on s’intéresserai à la différents compostant utiliser pour réaliser le solution micro- services du projet "Ubilab". 2.1 Architecture micro-service L’architecture des micro-services c’est une méthode utiliser pour développement de systèmes logiciels. En fait, cette architecture permet de traiter une application comme un ensemble des petits services chaque service considérer comme un projet à part. Comme présente la figure ci-dessous la différence entre architecture micro-service et architecture monolithique : Figure 2.1 – Architecture micro-services et architecture monolithique L’architecture micro-services développe une application comme un ensemble de petits services. Chaque service fonctionne moyennant son propre processus qui communique avec des mécanismes légers. Les services sont développés autour des compétences métiers qui sont déployés d’une façon indépendante par un processus automatisé. Ils sont autonomes Rapport de Projet de Fin d’études 9
  • 22. CHAPITRE 2. Architecture Micro-service et isolés mais aussi ils peuvent communiquer entre eux pour pourvoir créer l’ensemble du fonctionnalités nécessaires. Les micro-services sont généralement gérer par des petites équipes avec susamment d’autonomie. Chaque équipe peut modifier ou supprimer l’im- plémentation d’un service dans un micro-services avec un impact minimal sur le reste de système. Ils ont plusieurs avantages et inconvénients sa dépend du cas dans lequel ils sont utilisés. 2.1.1 Les Avantages de l’architecture des micro-services Dans la suite, nous présentons l’ensemble des avantages puisqu’il est nécessaire de connaître notre micro-service à quoi être capable de nous offrir et ses principaux avantages sont : • Limite les problèmes de la complexité : les services individuels peuvent être développés et mise en œuvre plus rapidement et aussi qu’ils sont assez simples de les comprendre et à maintenir. • Optimise les ressources : l’architecture micro-services permet à d’optimiser les ressources consacrées aux applications car chaque service est développé de maniérer indépendante par une équipe dédiée. • Rapidité de déploiement les nouvelles fonctionnalités : les micro-services rendent les déploiements des nouvelles fonctionnalités et les mises à jour très rapide et très facile. 2.1.2 Les inconvénients de l’architecture des micro-services Les architectures de micro-services, malgré leurs avantages font l’objet de critiques à cause de l’ensemble des inconvénients tell que : • Longue durée de lancement d’application : pour démarrer les applications à base de micro-services nous devons de lancer chaque service à part. • Incohérence de données : Les transactions commerciales mettant à jour les don- nées de plusieurs entreprises à la fois sont assez courantes. Ce type de transaction est simple à mettre en œuvre dans une application monolithique car il n’y a qu’une seule base de données. Toutefois, dans une application basée sur les micro-services, différentes bases de données appartenant à différents services devront être mises à jour [4]. Rapport de Projet de Fin d’études 10
  • 23. CHAPITRE 2. Architecture Micro-service • Complexité de faire les tests : les tests peuvent devenir très compliqués et très fastidieux à cause du déploiement distribué. Les retours d’expériences sur ce type d’architecture sont très positifs, donc ils devient un standard pour les grosses applications comme Amazone, Netflix, etc. 2.1.3 Solution proposée La figure 2.2 illustre l’architecture globale utiliser par "Ubilab" : Figure 2.2 – Ancient architecture monolithique d’Ubilab Comme présenté dans la figure, le projet "Ubilab" était basé sur architecture mono- lithique dans lequel ensemble de fonctionnalité sont localiser dans seul projet qui utiliser PostgresSQl et MongoDB comme deux bases de données. Et pour améliorer cet architecture, nous avons choisi d’utiliser une architecture base sur les micro-services comme s’explique la figure ci-dessus. Rapport de Projet de Fin d’études 11
  • 24. CHAPITRE 2. Architecture Micro-service Figure 2.3 – Nouvelle architecture d’Ubilab Cette architecture contient principalement : • Partie serveur : – Un broker RabbitMq (voir annexe A) : permet d’assurer la communication entre les ensembles des projets. En termes simples, il permet à un « Publisher » d’envoyer un message et permet à un « consommer » d’écouter ces messages. – Les micro-services (Identity, Laboratory, Talk) : les micro-services sont indé- pendant. – Une base donnée PostgresSQL : permet de partager les informations entre les projets. • Partie Client : – Partie Web : désigne un logiciel applicatif hébergé (Silk utilise Clever-cloud comme un hébergeur des différentes micro-services) sur n’importe quelle un serveur et accessible via un navigateur web (Chrome, Firefox, Microsoft Edge, etc.). Rapport de Projet de Fin d’études 12
  • 25. CHAPITRE 2. Architecture Micro-service – Partie mobile : désigne un logiciel applicatif développé pour un appareil mobile (smartphones) ce dernier utilise n’importe quel système d’exploitation mobile : Android, IOS. Et pour communiquer entre la partie client (web, mobile) et la partie serveur nous avez utilisé les API REST et API Websocket (voir annexe B). Conclusion Dans ce chapitre, nous avons commencé par comprendre l’architecture micro-service par situer leurs avantages et leur les inconvénients, ensuite en à étudier l’architecture utiliser dans notre solution. Le chapitre suivant consacré à la réalisation notre solution. Le chapitre suivant consacré à l’analyse et spécification des besoin. Rapport de Projet de Fin d’études 13
  • 26. Chapitre 3 Analyse et spécification des besoins Plan 3.1 Définition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.1 Les acteurs projet Identity . . . . . . . . . . . . . . . . . . . . . 15 3.2 Expression des besoins . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.2 Besoins non fonctionnel . . . . . . . . . . . . . . . . . . . . . . 18 3.3 Vue globale du système . . . . . . . . . . . . . . . . . . . . . . 18 3.3.1 Vue globale du projet Talk . . . . . . . . . . . . . . . . . . . . 18 3.4 Raffinement des cas d’utilisation . . . . . . . . . . . . . . . . . 20 3.4.1 Raffinement des cas d’utilisation du projet Identity . . . . . . 20 3.4.2 Raffinement des cas d’utilisation du projet Laboratory . . . . . 22 14
  • 27. CHAPITRE 3. Analyse et spécification des besoins Introduction Ce chapitre sera divisé en deux parties : dans lequel nous identifions les acteurs interve- nants dans chaque micro-service ensuite nous allons commencer par identifier les ensembles de besoins fonctionnels et non fonctionnels de notre solution. Une fois faite cette étape nous mettrons en valeur la deuxième partie dans lequel nous modélisions ces besoins à travers les diagrammes de cas d’utilisation de l’UML. 3.1 Définition des acteurs Avant commencer de situer l’ensemble de besoins fonctionnels et non fonctionnels il faut d’abord présenter les acteurs qui sont en contact direct avec chaque service et profitent de différents accès aux données. 3.1.1 Les acteurs projet Identity Le seul actionneur dans le projet Identity c’est les administrateurs de compte "Ubilab" qui permet de faire : – La gestion d’utilisateurs quel que soit leurs rôles. – La gestion des groupes. – La gestion d’archive utilisateurs. – La gestion de conventions. 3.1.1.1 Les acteurs projet Laboratory Dans le projet Laboratory il y’a que les administrateurs de compte "Ubilab" qui sont responsable à : – La gestion de permission d’accès. – La gestion d’abonnement. – Configuration d’examens. – Configuration communication dans "Ubilab". Rapport de Projet de Fin d’études 15
  • 28. CHAPITRE 3. Analyse et spécification des besoins 3.1.1.2 Les acteurs projet Talk Les acteurs de Talk principalement sont : • Les administrateurs sont responsables à : – La gestion de discussion de groupe ("Channel général", "Channel support") • Les personnels de laboratoire (les infirmiers, les médecines, les biologistes, etc.) sont responsables de : – Les réaction sur les messages. – Les partage de fichiers. – Les envois et réceptions de messages. 3.2 Expression des besoins Cette étape vise à déterminer la vision globale de notre projet en mettant en valeurs les besoins fonctionnels et non fonctionnels. 3.2.1 Besoins fonctionnels 3.2.1.1 Projet Identity Les besoins fonctionnels de projet Identity sont : • Gestion des utilisateurs : L’application doit permettre aux administrateurs de créer un utilisateur quel que soit son rôle (les infirmiers, les médecines, les biolo- gistes, etc.), modifier ses informations, le supprimer, mettre en pause ou archiver l’utilisateurs, envoyer le rappel, ajouter un commentaire, supprimer un commen- taire, rechercher les utilisateurs selon plusieurs filtre (sexe, profile, groupe, téléphone, adresse ,etc.) et exporter la liste des utilisateurs sous format Excel. • Gestion des groupes : L’application doit permettre aux administrateurs de créer un groupe, modifier ses informations, le supprimer, ajouter un utilisateur à ce groupe, enlever un utilisateur à ce groupe et rechercher un ou plusieurs groupes. • Gestion des conventions : L’application doit aussi permettre aux administrateurs d’attacher une convention papier signe a une convention, voir la convention papier signée, remplacer la convention papier signée et annuler la signature papier. Rapport de Projet de Fin d’études 16
  • 29. CHAPITRE 3. Analyse et spécification des besoins 3.2.1.2 Projet Laboratory Les besoins fonctionnels de projet Laboratory sont : • Gestion de l’interface web : Laboratory permet aux administrateurs de modi- fier logo de laboratoire, modifier le favicon de l’application web, choisir le type de connexion, activer la connexion patiente, choisir la durée maximum de session, gérer les permissions d’accès et gérer l’abonnement. • Gestion de la configuration du manuel : Laboratory offre aux administrateurs possibilités de créer nouvelle catégorie, supprimer la catégorie, modifier la catégorie et choisir une version du manuel des fiches. • Gestion de la communication dans Ubilab : Laboratory permet aux adminis- trateur d’ajouter mail de contact, ajouter texte de contact, personnaliser le mail envoi de s’identifiants, ajouter une adresse mail d’envoi en copie cachée, tester l’en- voi mail envoi des identifiants, personnaliser le SMS d’envoi des identifiants, tester l’envoi SMS, activer le notifications automatique de rappel, ajouter le période notifi- cation automatique, personnaliser le mail de rappel, personnaliser le SMS de rappel, tester l’envoi de SMS et Email de rappel et afficher le facturation des SMS. • Gestion d’application mobile : Il offre aussi aux administrateurs possibilités de modifier image d’accueil dans l’application, modifier le mot du labo, ajouter lien vers serveur de résultat professionnels, activer l’accès au serveur de résultats professionnels sur l’application, activer l’accès au service externe de prise de rendez- vous et ajouter lien vers le service externe de prise de rendez-vous. 3.2.1.3 Projet Talk Les besoins fonctionnels de micro-service Talk sont : • Gestion des messages : Talk offre aux personnels de laboratoire possibilités d’en- voyer des messages instantané, réceptions de messages, activer les notifications, ré- agir à un ou plusieurs messages et partager des fichiers. • Gestion de discussion de groupe : Talk permet aux administrateurs d’ajouter ou supprimer un ou plusieurs utilisateurs à une discussion de groupe. • Gestion des conventions : L’application doit aussi permettre aux administrateurs d’attacher une convention papier signe a une convention, voir la convention papier signée, remplacer la convention papier signée et annuler la signature papier. Rapport de Projet de Fin d’études 17
  • 30. CHAPITRE 3. Analyse et spécification des besoins 3.2.2 Besoins non fonctionnel Il s’agit d’ensemble des contraintes technique caractérisent l’ensemble de micro-services en matière de performance. Nous citons essentiellement : • Modularité : Chaque micro-service doit offrir une modularité de paramétrage à ses utilisateurs pour pouvoir l’adapter à des besoins. • Sécurité : L’application doit garantie de contrôles de sécurité réservant l’accès aux données aux utilisateurs appropriés. Donc, il faudrait assurer la bonne gestion des droits d’accès ainsi que les rôles. • Performance : Chaque micro-service doit disposer un temps de réponse optimal à travers le respect des bonnes pratiques de développement logiciel et par la pré- paration de l’environnement matériel adéquat (bande passante suffisante, serveurs performants, etc.). 3.3 Vue globale du système Cette étape consacrée à déterminer la vision globale de notre projet, mais dans notre cas en à choisir de présenter que la vue globale du projet Talk car ce dernier contient plusieurs acteurs. 3.3.1 Vue globale du projet Talk Le diagramme ci-dessous illustre le diagramme de cas d’utilisation global de projet Talk. Chaque acteur dispose ensemble des permissions qui lui sont accordées ainsi d’un nombre de fonctionnalités relatives à son rôle. Rapport de Projet de Fin d’études 18
  • 31. CHAPITRE 3. Analyse et spécification des besoins Figure 3.1 – Diagramme de cas d’utilisation globale du projet Talk La description scénariste du cas d’utilisation « Afficher les informations d’un message » est présentée dans le tableau ci-dessous. Table 3.1 – Description scénariste du cas d’utilisation « Afficher les informations d’un message» Cas d’utilisation : Afficher les informations d’un message. Résumé : Un utilisateur peut visualiser l’information de chaque message. Acteurs : Utilisateur. Pré-condition : L’utilisateur est authentifié et abonnée à une Channel Talk . Scénario nominal : 1- L’utilisateur clique sur le menu puis choisir « Talk ». 2- L’utilisateur Clique une première fois sur un message pour afficher ensembles des informations. 3- Les informations d’un message sont affichées. Scénarios alternatifs : Si l’utilisateur clique deux fois successives sur le message les informations appa- raissent très vite et disparaissent. Rapport de Projet de Fin d’études 19
  • 32. CHAPITRE 3. Analyse et spécification des besoins 3.4 Raffinement des cas d’utilisation Après avoir présenté le diagramme de cas d’utilisation global de projet Talk, Nous allons maintenant situer les diagrammes des cas d’utilisation raffinés pour chaque projet. 3.4.1 Raffinement des cas d’utilisation du projet Identity La figure 3.2 présente le digramme de cas d’utilisation de la rubrique administration pour le projet Identity. Rapport de Projet de Fin d’études 20
  • 33. CHAPITRE 3. Analyse et spécification des besoins Figure 3.2 – Digramme de cas d’utilisation de la rubrique administration pour le projet Identity La description scénariste du cas d’utilisation « Créer un utilisateur » est présentée dans le tableau ci-dessous. Rapport de Projet de Fin d’études 21
  • 34. CHAPITRE 3. Analyse et spécification des besoins Table 3.2 – Description scénariste du cas d’utilisation « Créer un utilisateur » Cas d’utilisation : Créer un utilisateur. Résumé : Un administrateur peut créer un utilisateur (Administrateur, coursier, biologiste, médecin, client, sage-femme, etc..) en spécifiant les ensemble informations relatives à ce dernier. Acteurs : Administrateur. Pré-condition : L’administrateur est authentifié. Scénario nominal : 1- L’administrateur se rend à la page création d’un nouvel utilisateur. 2- Le système affiche le pop-up qui contient quatre étapes. 3- L’administrateur saisit l’ensemble des informations nécessaires et choisit de les enregistrer. Le système enregistre le nouvel utilisateur, ensuite enregistre dans archive l’action de création d’un nouvel utilisateur pour cet administrateur et enfin réaffiche la page création d’un nouvel utilisateur réinitialisée avec un message de succès en mémé temps le système envoie un Email qui contient l’identifiant et mots de passe associe à ce nouvel utilisateur. Scénarios alternatifs : E1 : Erreur dans les informations saisies dans chaque étape. 1- Le système affiche le message d’erreur. 2- Le système affiche le pop-up qui contient quatre étapes. 3.4.2 Raffinement des cas d’utilisation du projet Laboratory La figure 3.3 illustre le digramme de cas d’utilisation de la rubrique administration pour le projet Laboratory. Rapport de Projet de Fin d’études 22
  • 35. CHAPITRE 3. Analyse et spécification des besoins Figure 3.3 – Digramme de rubrique administration pour le projet Laboratory Le tableau ci-dessous décrit le scénario du cas d’utilisation « Modifier logo de labora- toire » Rapport de Projet de Fin d’études 23
  • 36. CHAPITRE 3. Analyse et spécification des besoins Table 3.3 – Description scénariste du cas d’utilisation « Modifier logo de laboratoire » Cas d’utilisation : Modifier logo de laboratoire Résumé : Un administrateur peut modifier logo de leur laboratoire en choisissant une image qu’a la taille 96*649px ou 96*96px. Acteurs : Administrateur Pré-condition : L’administrateur est authentifié Scénario nominal : 1- L’administrateur se rend à la page personnaliser Ubilab. 2- Le système affiche le page. 3- L’administrateur télécharge logo associe à leur laboratoire. 4- Le système envoie l’image à un micro-service qui s’appelle Ubilab-Uplod dans la quel en enregistre l’image dans le serveur ensuite Ubilab-Uplod envoie au système URL associe à cette image et enfin le système enregistre cette URL et afficher le nouveau logo. Scénarios alternatifs : E1 : Erreur dans le téléchargement de logo. • Le système affiche le message d’erreur. Conclusion Dans ce chapitre, nous avons commencé par identifier l’ensemble des acteurs de notre application ainsi que les différents besoins fonctionnels et non fonctionnels. Donc après l’étude développée précédemment nous guide dans le chapitre qui suivent : la conception et la réalisation de notre solution. Rapport de Projet de Fin d’études 24
  • 37. Chapitre 4 Conception de notre solution Plan 4.1 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2.1 Projet Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2.2 Projet Laboratory . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2.3 Projet Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3 Diagrammes séquences . . . . . . . . . . . . . . . . . . . . . . . 32 25
  • 38. CHAPITRE 4. Conception de notre solution Introduction Avant de commencer la réalisation ou le développement de chaque projet qui répond aux besoins demandés il est nécessaire de faire sa conception. Dans cette étape, nous allons détailler l’architecture logicielle de notre solution ainsi que la conception détaillée. 4.1 Architecture logicielle La figure 4.1 représente l’architecture logicielle commune des différents micro-services. Figure 4.1 – Architecture logicielle L’architecture de la figure 4.1 est composée de • Couche d’accès aux donnés (DAO) : Cette couche permet d’implémenter le pattern DAO. Elle contient l’ensemble des éléments permettant l’accès aux données de la base. Cette couche interroge les bases Rapport de Projet de Fin d’études 26
  • 39. CHAPITRE 4. Conception de notre solution reliées avec elle indépendante de la logique métier et offre à la couche logique métier toutes les données nécessaires. • Couche métier : C’est la couche responsable à la logique métier. Cette couche est indépendante de toute forme d’interface avec l’utilisateur. Elle interagit avec la couche service et la couche accès aux données et pour fournir le résultat final des exécutions qui sera ensuite transmis vers couche service. • Couche service : Cette couche est responsable de la communication entre la couche interface utilisa- teur et la logique métier. Elle est constituée d’un ensemble de Web services englobant les traitements métier. • Sérialiseurs des modèles métiers : Les sérialiseurs des modèles métiers c’est un composant obligatoire du Framework Play2.6 scala. Ils permettent aux données complexes tels que les instances du modèle d’être convertis en types de données native scala qui peuvent par la ensuite être facilement rendues en format XML, JSON ou autres types de contenu. • Couche interface utilisateur : C’est la couche qui offre à l’utilisateur de piloter l’application. Elle interagit direc- tement avec la couche service pour récupérer les données nécessaires et pour lancer ensemble des traitements. La couche interface utilisateur a été utiliser avec l’utili- sation du pattern Model View Controller (MVC). 4.2 Conception détaillée Analyse et spécification des besoin de chaque micro-services établies dans le chapitre précédent vont nous permettre d’identifier les différentes classes. En utilisant les dia- grammes du langage UML, nous allons entamer dans cette partie la conception détaillée de notre solution. Par soucis de simplification, nous allons présenter des exemples de classes pour chaque micro-service. 4.2.1 Projet Identity 4.2.1.1 Diagramme de class La figure 4.2 illustre présente le digramme de class des entités utiliser en projet Talk. Rapport de Projet de Fin d’études 27
  • 40. CHAPITRE 4. Conception de notre solution Figure 4.2 – Diagramme de classe de la couche modelé de projet Identity • UserSearch : L’entité qui contient l’ensemble des informations associe à utilisateur. • Role : Chaque utilisateur peut avoir plusieurs rôles. • UserGroupe : Cette classe représente l’ensemble des groupes qu’utilisateur peut les joindre. • Laboratory : Cette entité qui représente laboratoire. • ProfileRight : Cette classe présente ensemble de droite associe à chaque profil. • User : Classe qui représente l’utilisateur de projet Identity. 4.2.1.2 Schéma relationnel • User(idUser, firstName, lastName, email, #id_laboratory, #id_profile) • UserSearch(idUserSearch, firstName, lastName, #id_user ) • Role(idRole) • UserGroup(idUserGroup, name, created, description) • Profile(idProfile, name) • ProfileRight(idProfileRight, name, display) • Laboratory(idLaboratory, name, sikey, created) Rapport de Projet de Fin d’études 28
  • 41. CHAPITRE 4. Conception de notre solution • User_role(#user_id, #role_id) • UserGroup_user(#id_use_group, #id_user) • ProfileRigh_Profile(#id_profile_right, #id_profile) 4.2.2 Projet Laboratory 4.2.2.1 Diagramme de class La figure 4.3 illustre présente le digramme de class des entités utiliser en projet Labo- ratory Figure 4.3 – Diagramme de classe de la couche modelé de projet Laboratory • LaboratoryConfig : Cette entité contient les ensembles de configuration associe à un laboratoire. • LaboratoryGroup : Cette classe désigne ensemble des groupes des laboratoires. • LaboratoryOffice : Cette classe présente ensembles des bureaux diffuse dans tout le monde. • AnalysisFieldToHide : Cette entité présente ensemble des analyses associe à chaque profil. • AnalysisField : Cette classe présente Information des analyses. Rapport de Projet de Fin d’études 29
  • 42. CHAPITRE 4. Conception de notre solution • UserGroupRight : Cette entité désigne ensemble des droites associe à chaque groupe dans laboratoire. 4.2.2.2 Schéma relationnel • LaboratoryConfig(id, analysisImageCdnUrl, welecomeMailText, created, weleco- meSMStext, homeSMSText, homeImageCdnUrl, maxSessionTime, hasViste, add- LaboName, #id_laboratory). • LaboratoryGroup(id, name, sikey, email). • UserGroupRight(id, name, display, #idLaboratory). • AnalysisFieldToHide(id, created, #field, #id_laboratory). • AnalyssisField(code, name, description). • LaboratoryOffice(id, name, isTechnicalPlatform, address, codePostal,sity, #id_laboratory) . • Laboratory(idLaboratory, name, sikey, isCussomer, urlIOS, urlandroid, created, #id_laboratoryGroup ). 4.2.3 Projet Talk 4.2.3.1 Diagramme de class La figure 4.2 illustre présente le digramme de class des entités utiliser en projet Talk : Rapport de Projet de Fin d’études 30
  • 43. CHAPITRE 4. Conception de notre solution Figure 4.4 – Diagramme de classe de la couche modelé de projet Talk • Room : Cette classe représente une salle de discussion où on peut échanger textes ou fichier sur le sujet tous les utilisateurs qu’on veut cette "Room" peut être soit salle de discussion direct "OneToOneChannel" (contient maximum deux utilisateurs), soit salle de discussion privé "PrivateChannel" ou bien salle discussion public "Channel". • Message : Cette entité décrit ensemble des messages envoyer par utilisateur vers les salles de discussion. • Profile : Chaque utilisateur posséde un profil (sage-femme, IDE, médecine, admi- nistrateur, etc.) • Reaction : L’utilisateur peut réagir à un message par un réaction. • Session : en créer l’entité Session pour indiquer le période pendant laquelle l’utilisa- teur et bien connecter à notre projet et sa nous permettront de facilité distribution de message à chaque salle discussion dans laquelle l’utilisateur a été abonné. • User : Classe qui représente l’utilisateur de projet Talk. Rapport de Projet de Fin d’études 31
  • 44. CHAPITRE 4. Conception de notre solution 4.2.3.2 Schéma relationnel Le schéma relationnel est constitué les différents schémas de tables de base de données. Voici les schémas relationnes de projet Talk : • Room (idRoom, name, isPublic, isSupport, isGeneral) • Message(idMessage, sendDate, text) • User(idUser, firstName, lastName, image ,#Id_profile) • Profile(idProfile, name) • Session(idSession) • Reaction(idReaction,value,#id_message) • Message_Room(#IdMessage, #id_room) • Room_Session(#idRoom, #id_session ) • User_Room(#idUser, #Id_room ) • User_Reaction(#idUser, #Id_reaction ) 4.3 Diagrammes séquences Le diagramme 4.4 illustre présente le diagramme de séquence de création d’un groupe : Rapport de Projet de Fin d’études 32
  • 45. CHAPITRE 4. Conception de notre solution Figure 4.5 – Diagramme de séquence de création d’un groupe Le diagramme séquence ci-dessus explique les étapes de création d’un groupe par ClientHttp Web d’un laboratoire. Ce dernier doit saisir l’ensemble des formations néces- saires "groupToCreate". Les données saisies seront envoyées dans une requête HTTP vers GroupController. Si les informations sont valides et l’administrateur est bien authentifié, le Controller fait appelle à la méthode qui createGroup qui se trouve dans la couche métier (GroupSer- viceWrite).Par la suite cette méthode fait un autre appelle pour une autre méthode qui s’appelle getGroup qui permet de vérifier si le nom de groupe existe déjà dans notre base donnée si non GroupServiceWrite envoie notre objet vers RabbitMQ (voir Annexe pour enregistrer dans la base de données associé à l’archive et envoie un "Int" a GroupControl- ler qui lui informe que la création est bien passé. Par la suite celui-ci envoie un réponse HTTP avec un statuts 200. Si le nom du groupe excite déjà le GroupServiceWrite envoie une exception à GroupCon- troller et lui envoie à ClientHttp une réponse HTTP avec un statuts 417 "Expectation Failed". Dans l’autre cas : - Si ClientHttp n’est pas un administrateur, GroupController envoie à ClientHttp une Rapport de Projet de Fin d’études 33
  • 46. CHAPITRE 4. Conception de notre solution réponse HTTP avec un statuts 401 "Unauthorized". - Si le format des données saisie est invalide, GroupController envoie à ClientHttp une réponse HTTP avec un statuts 417 "Expectation Failed". Conclusion Tout au long de ce chapitre, nous avons étudié l’architecture logiciel et la conception de notre solution. Dans un premier lieu, nous avons décrire l’architecture de notre application qui définit la cohérence entre les différentes couches. Par la suite, nous avons détaillé notre conception à travers de classes pour chaque micro-services et de séquences relatives à notre solution. Le chapitre suivant consacré à la réalisation notre solution. Rapport de Projet de Fin d’études 34
  • 47. Chapitre 5 Réalisation Plan 5.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . 36 5.1.1 Environnement Logiciel . . . . . . . . . . . . . . . . . . . . . . 36 5.1.2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.3 Mode de fonctionnement de l’application . . . . . . . . . . . . 40 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 35
  • 48. CHAPITRE 5. Réalisation Introduction Après avoir traité la partie conception de notre travail. L’étape suivante, c’est la réalisa- tion. Nous commencerons par expliquer nos choix technologiques nous concluons par la présentation des interfaces réalisées. 5.1 Environnement de travail Nous allons présenter dans cette partie les logiciels et les technologies que nous avons utilisés pour la réalisation notre solution. 5.1.1 Environnement Logiciel 5.1.1.1 Intellij IDEA Community Edtion Intellij IDEA Community est un environnement de développement intégré (IDE) dé- veloppé par la société tchèque JetBrains et utilisé pour la programmation en Scala, Ja- vaScript, Ruby, etc. Il fournit une analyse de code, un débogueur graphique, un testeur d’unité intégrée et s’intègre parfaitement avec les systèmes de contrôle de version tel que SVC ou GIT. Cet IDE soutient essentiellement le développement Web avec Scala. Multi-plateforme, Intellij admet deux éditions une Community et une Professional (sous licence)[5]. 5.1.1.2 GIT Git est un logiciel de gestion de versions décentralisé. Il est conçu pour être efficace tant avec les petits projets que les plus importants[6]. Créé par Linus Torvalds, auteur du noyau Linux, Git a spécialement été créé pour le développement du noyau linux [7]. Ces principaux atouts sont : • Une architecture décentralisée : contrairement à des outils comme Apache subversion (SVN) ou Git fonctionne de décentralisée. Sur Son disque dur, Chaque collaborateur détient une copie du projet avec tout son historique. Les ensembles des collabora- teurs du projet peuvent se partager les données de projet sans passer directement par un serveur. • Des sites communautaires : des sites Web comme GitHub, GitLab ou Bitbucket ont mis en place un espace associe aux utilisateurs de Git. Grace à dépôt à distance, Il Rapport de Projet de Fin d’études 36
  • 49. CHAPITRE 5. Réalisation permet aux collaborateurs de visualiser le projet, consulter les modifications ainsi que commenter des lignes décode. • Des interfaces graphiques : des interfaces graphiques pour Git permettent aux utili- sateurs de faciliter son utilisation en prenons comme exemple : SourceTree, Tortoi- seGit, giKt, etc. Ainsi qu’ il y’a des plugins intégrés dans des IDE. Pour ce projet, nous avons utilisé SourceTree comme interface graphique. 5.1.1.3 Postico Postico est un outil destiné à l’administration des bases de données de Postgresql. Cet outil propose une interface graphique comme alternative à l’interpréteur de commande fournis avec Postgresql. Il permet de gérer plusieurs serveurs de base de données et propose différentes méthodes d’authentification (identifiant/mot de passe, SSL, tunnel SSH)[8]. 5.1.1.4 Postman C’est un logiciel où aussi peut être un plugin dans le navigateur Chrome qui permet de faire des tests sur les services Web REST. Il permet de créer facilement des requêtes HTTP simples ou complexes, ainsi que les enregistrer et d’analyser les réponses envoyées par l’API. 5.1.1.5 PostgreSQL PostgreSQL est un système de gestion de base de données relationnelle et objet. L’une des principales qualités de PostgreSQL est d’être un logiciel gratuit et open source. Post- greSQL possède de nombreuses caractéristiques faisant de lui un SGBDR robuste. Il dis- pose d’interface graphique, des bibliothèques facilitant l’accès aux données à partir des programmes écrit en (JAVA, C, C++, Perl, etc) et d’une API ODBC permettant à n’im- porte quelle application supportant ce type d’interface d’accéder à des bases de données de type PostrgreSQL[9]. 5.1.2 Technologies Les technologies utilisées au cours de développement de notre solution sont : Rapport de Projet de Fin d’études 37
  • 50. CHAPITRE 5. Réalisation 5.1.2.1 Framework Play Scala Play est un Framework Web écrit en Scala gratuit et open source, qui encourage le développement rapide et propre. Play est un Framework web qui suit le patron de conception « Design pattern » MVC (Model View Controller) où la couche de présentation est divisée en une vue et une couche de contrôleur. La figure 5.1 illustre l’architecture logicielle du Framework Play Scala. Figure 5.1 – Architecture logicielle du Framework Play scala Toutes les requêtes HTTP suivent le même chemin : • Une requête HTTP est reçue par le Framework. • Le composant "Route" tente de trouver la route la plus spécifique capable d’accepter cette requête. La méthode d’action correspondante est ensuite invoquée. • Le code de l’application est exécuté. • Si une vue complexe doit être générée, un fichier modèle est rendu. • Le résultat de la méthode d’action (code de réponse HTTP, contenu) est ensuite écrit en tant que réponse HTTP. 5.1.2.2 JSON Web Token Les JWT sont des jetons générés par un serveur lors de l’authentification d’un utilisa- teur sur une application web, et qui sont ensuite transmis au client. Pourquoi JWT Dans Rapport de Projet de Fin d’études 38
  • 51. CHAPITRE 5. Réalisation le cas d’une application où on consomme des API REST. Le transfert des données se fait à travers des requêtes HTTP et sous format JSON. Et c’est comme ça que l’authentification avec JWT fonctionne[10]. 5.1.2.3 Test unitaires En programmation, les tests unitaires constituent une procédure permettant de vérifier le bon fonctionnement d’une partie précise d’un logiciel. Ils aident à trouver les erreurs rapidement, à sécuriser la maintenance et réduire son coût et à documenter le code source. Les tests unitaires et de composants constituent la base du développement En effet, l’approche TDD permet de garantir la qualité du code et la fréquence des évolutions s. Pour ce type de test, nous avons utilisé la librairie relative au Framework Play qui s’appelle «ScalaTest». Pour les tests unitaires, en a fait un descriptif détaillé des tests effectués pendant le stage est donné dans l’annexe C «Test unitaires». 5.1.2.4 Les pull-request Un fork désigne une copie d’un dépôt. En effet, par défaut il n’est pas possible de faire de commit sur un dépôt qui ne nous appartient pas. Du coup, les services ont introduit cette notion de fork qui permet de se retrouver avec un dépôt sur le quelle on aura la permission d’écriture. La notion de pull-request va de pair avec le système de Fork. Une fois que l’on a travaillé sur notre fork on souhaite souvent proposer à l’auteur original nos modifications. On fera alors un pull-request qui consiste tout simplement à demander à l’auteur original de merge nos modifications. Ce processus est géré de manière quasi automatique par GitHub et Bitbucket[11]. Pour les pull-request, monsieur Guillaume BADIN c’est la seule personne que peut merge vos modifications. La figure ci-dessus pressent un exemple d’un pull-request. Rapport de Projet de Fin d’études 39
  • 52. CHAPITRE 5. Réalisation Figure 5.2 – Demande d’un pull-request 5.1.3 Mode de fonctionnement de l’application Dans cette partie, nous allons présenter les principales fonctionnalités attendues de l’API sous forme d’interfaces Web ou peut aussi sous forme d’interface mobile. Notre API a été développer en partie "Back-End" et consommer par une application Web (partie "Front-End") ou partie mobile en utilisant les Framework Angular 4.4.6 et Bootstrap ou en utilisant ASP.net en partie mobile. Nous présentons par la suite les principales interfaces de chaque mirco-sercice. 5.1.3.1 Identity Pour Identity, on a choisi de décrire que le travail qu’on a réalisé pour les utilisateurs et les groupes. Groupe : La figure 5.3 illustre l’interface qui présente la liste des groupes. Il dispose des fonc- tionnalités qui suivent : Rapport de Projet de Fin d’études 40
  • 53. CHAPITRE 5. Réalisation • Rechercher un groupe. • Ajouter un nouveau groupe. • Ajouter ou enlever des utilisateurs. • Supprimer le groupe. Figure 5.3 – La liste des groupes Les Figures 5.4 et 5.5 présentent les informations du groupe et aussi les membres utilisa- teurs appartient à ce groupe. Figure 5.4 – Les informations du groupe Rapport de Projet de Fin d’études 41
  • 54. CHAPITRE 5. Réalisation Figure 5.5 – Les membres du groupe Utilisateur : La ci-dessous présente l’interface qui présente la liste des utilisateurs. Il offre des fonctionnalités qui suivent : • Recherche un utilisateur. • Filtrer les utilisateurs par des filtres dynamiques. • Exporter les utilisateurs. • Joindre l’utilisateur à un groupe. • Mettre en pause l’utilisateur. • Archiver l’utilisateur. Rapport de Projet de Fin d’études 42
  • 55. CHAPITRE 5. Réalisation Figure 5.6 – Les membres du groupe Les figures ci-dessous présente les 4 étapes qu’il faut faire pour créer un nouvel utilisateur. Figure 5.7 – Étape 1/4 : Identité Figure 5.8 – Étape 2/4 : informa- tions complémentaires Rapport de Projet de Fin d’études 43
  • 56. CHAPITRE 5. Réalisation Figure 5.9 – Étape 3/4 : informa- tions de contact Figure 5.10 – Étape 4/4 : mot de passe 5.1.3.2 Laboratory À ce stade, nous allons choisir quelque capture d’écrans concrète qu’on réaliser dans le projet Laboratory : Configuration Général : La figure 5.11 illustre l’interface de modification de logo et favicon : le logo se trouve dans les étapes d’identification ou dans l’entête du menu des paramètres et le favicons est utilisé comme icône dans la barre d’adresse, dans les onglets et dans les favoris de votre navigateur. Rapport de Projet de Fin d’études 44
  • 57. CHAPITRE 5. Réalisation Figure 5.11 – Personnaliser Ubilab Nous présentons dans la figure 5.12 le page permet de définir le type de connexion à logiciel Ubilab sachant que la traçabilité sur les modifications apportées à Ubilab n’est pas appliquée que sur les personnes se connectant avec un compte. Rapport de Projet de Fin d’études 45
  • 58. CHAPITRE 5. Réalisation Figure 5.12 – Connexion à Ubilab La figure 5.13 illustre présente la page qui permet d’activer le mail récapitulatif et aussi ajouter des mails récapitulatifs pour conserver une trace de ces modifications des examens partagés. Configuration examens : La figure 5.14 illustre présente la page qui permet d’activer le mail récapitulatif et aussi ajouter des mails récapitulatifs pour conserver une trace de ces modifications des examens partagés. Rapport de Projet de Fin d’études 46
  • 59. CHAPITRE 5. Réalisation Figure 5.13 – Gestion du notification La ci-dessous présente l’interface qui permet de choisir mode affichage de prélèvement. Figure 5.14 – Mode de prélèvements Nous présentons dans la figure 5.15 le page que nous pouvions indiquer nouvelle numéro de version des examens. Rapport de Projet de Fin d’études 47
  • 60. CHAPITRE 5. Réalisation Figure 5.15 – List du catalogue d’examens Configuration manuel : L’administrateur peut aussi consulter la liste des catégories des fichiers et ajouter une nouvelle catégorie ainsi peut le supprimer si ce dernier n’est pas attaché à des fiches comme montre le figure 5.16, 5.17 et 5.18. Figure 5.16 – List des catégories Rapport de Projet de Fin d’études 48
  • 61. CHAPITRE 5. Réalisation Figure 5.17 – Ajout d’une catégo- rie Figure 5.18 – Suppression d’une catégorie Communication : La figure 5.19 illustre présente l’interface qui permet de personnaliser le mail d’envoi des d’identifiant par choisir le contenu du mail ainsi que l’objet ou même par ajouter une adresse mail d’envoie en copie cachée. Figure 5.19 – Liste des catégories Rapport de Projet de Fin d’études 49
  • 62. CHAPITRE 5. Réalisation La ci-dessous présente l’interface qui permet d’activer les notifications de rappel, choi- sir une délai de la période d’inactivité en jours et choisir la préférence d’envoi : SMS uniquement, Moi uniquement, etc. Ces notifications de rappel sont envoyées à toutes les IDE qui ne sont pas connectées à "Ubilab" pendant une certaine piéride. Figure 5.20 – Rappels automatiques Configuration application La figure 5.20 présente la page qui permet de modifier l’image d’accueil, cette image se trouve dans la page d’accueil d’application. Elle permet une meilleure personnalisation et un environnement plus familier pour les utilisateurs. Figure 5.21 – Image accueil application Rapport de Projet de Fin d’études 50
  • 63. CHAPITRE 5. Réalisation La ci-dessous présente l’interface qui permet à l’administrateur de modifier le mot du labo : c’est le texte qui apparaît dans la partie « Contacter le laboratoire » dans les paramètres de l’application mobile. Figure 5.22 – le mot du labo 5.1.3.3 Talk A l’aide des captures d’écran nous Allons ici décrire notre travail réalise pour le projet Talk ce travail devise en deux parties : Web et mobile. Web : La figure 5.15 représente l’interface principale pour Talk version web. Rapport de Projet de Fin d’études 51
  • 64. CHAPITRE 5. Réalisation Figure 5.23 – Interface principale pour Talk version web À gauche, nous proposons un menu "sidebar" de navigation comportant la liste de chaînes : publique comme Général, Random et les chaînes Direct. En haut, nous trouvons le nombre de participants dans la chaîne et le date de dernier message envoyer dans la chaîne. Au milieu nous présentons la liste de messages et chaque message contient le nom d’utilisateur ainsi que le date d’envoi du message et les réactions. À droite, la liste de participants et aussi les fichiers partages dans cette chaîne et un "checkbox" qui permet de Désactiver les notifications. Mobile : Les figures illustres l’interface Talk dans application mobile. Ils présentent le page chat dans les cas suivent : • S’il n’y a pas des messages. • Si le message a été envoyé. • Si le message n’a pas été envoyé dans ce cas Talk vous offre la possibilité de réessayer d’envoyer un message. Rapport de Projet de Fin d’études 52
  • 65. CHAPITRE 5. Réalisation • Si un quelqu’un est en train d’écrire. Figure 5.24 – Page chat dans le cas il n’y a pas des messages Figure 5.25 – Indiquer l’état d’un message envoyé Rapport de Projet de Fin d’études 53
  • 66. CHAPITRE 5. Réalisation Figure 5.26 – Cas réessayer d’en- voyer un message Figure 5.27 – Interface pour un message non envoyé et si un utili- sateur en train d’écrire Conclusion À travers ce dernier chapitre, nous avions commencé par décrier l’environnement lo- giciel et ensembles des technologies que nous avons utilisées. Puis, nous avons présenté une description des fonctionnalités principales de chaque micro-service en utilisant des captures d’écrans. Rapport de Projet de Fin d’études 54
  • 67. Conclusion Le présent rapport illustre le travail des six mois établis en vue d’obtention du diplôme national d’ingénieur en télécommunication à Silk. Durant ce stage, nous sommes arrivés à construire une solution micro-services d’ensembles fonctionnalité déployer par Silk qui offre : • La distribution de tous les traitements des données. • L’optimisation des ressources consacrées aux application. • La facilité de détection d’erreurs. Nous sommes arrivés intègres un nouveau projet POC "Talk". Ce dernier permet aux clients de Silk d’échanger par des messages instantanés en temps réels avec utilisateurs concernant : les actualités, les non conformités, les rappels de mises à jour, etc. En utilisant la méthode agile Scrum, sur le plan méthodologique qui nous a permis de réaliser les ensembles des objectifs mis en place au début du stage en respectant la planification initiale et le date limite associes à chaque tâche. Sur le plan technique, nous avons développé nos connaissances dans le domaine de développement informatique pour renforcer mon intérêt pour le domaine télécommunica- tion. Néanmoins, il existe d’autres améliorations qui peuvent être implémentées pour : • Optimiser la communication entre les micro-services. • Ajouter des nouvelles fonctionnalités dans le projet Identity et Laboratory comme intégrer les ensembles d’actions faite par les utilisateurs dans projet Ubilab-Result et Ubilab-Visi dans le système archivages. • Avoir des discussions communes entre différentes laboratoires dans la région France entière. 55
  • 68. Références [1] “Les applications mobile au service du corps médical,” https://blog.axopen.com/ 2018/02/application-mobile-sante-hopital/, dernière Consultation : 30/08/2018. [2] “Ubilab,” http://ubilab.io/, dernière Consultation : 26/08/2018. [3] X. L. A. J. G. A Stellman, Understanding Scrum. O’Reilly Media, 2014. (Cité en page 4.). [4] “Documentation micro-service,” ://www.lemagit.fr/tribune/Microservices-avantages- et-inconvenients-de-la-nouvelle-structure-de-serveurs-web. [5] “Jetbrains documentation,” https://www.jetbrains.com/idea/documentation/, der- nière Consultation : 2018-08-15. [6] “Gestionnaire de version décentralisé,” https://www.projet-plume.org/fiche/git, der- nière Consultation : 2018-09-07. [7] “Git documentation,” http://doc.ubuntu-fr.org/git, dernière Consultation : 2018-08- 15. [8] “Postico documentation,” https://eggerapps.at/postico/l, dernière Consultation : 2018-08-18. [9] “Postgresql documentation,” https://www.commentcamarche.com/contents/ 814-postgresql-introduction, dernière Consultation : 2018-08-18. [10] E. Alpaydın, “Json documentation,” https://jwt.io/introduction/, dernière Consul- tation : 2018-05-18. [11] “Pull-request documentation,” https://www.grafikart.fr/formations/git/ fork-pull-request, dernière Consultation : 2018-05-18. 56
  • 69. CHAPITRE 5. Réalisation [12] “Services web ou api,” http://www.christian-faure.net/2012/10/08/ services-web-ou-api/, dernière Consultation : 2018-08-30. [13] “Api rest,” https://www.supinfo.com/articles/single/ 5642-qu-est-ce-qu-une-api-rest-restful, dernière Consultation : 2018-05-15. [14] “Web socket,” https://jmdoudoux.developpez.com/cours/developpons/java/ chap-websockets.php, dernière Consultation : 2018-08-28. [15] “Rabbitmq,” https://blog.eleven-labs.com/fr/rabbitmq-partie-1-les-bases/, note = Dernière Consultation : 2018-08-8. [16] “Documentation rabbitmq,” http://www.rabbitmq.com/documentation.html, der- nière Consultation : 2018-08-28. [17] “Actor akka,” https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html# Introduction, dernière Consultation : 2018-08-28. Rapport de Projet de Fin d’études 57
  • 71. Annexe A WebService Rest APIS et WEBSERVICE APIS Dans cette annexe, nous avons comprendre les classifications les déférents API’s. En matière de communication Web, nous pouvons identifier deux types d’API significatifs : les API de service Web (par exemple, SOAP, JSON-RPC, XML-RPC, REST) et les API Websocket. WebService Un service web est un protocole d’interface informatique de la famille des technologies web permettant la communication et l’échange des données entre applications et systèmes échange des données entre applications et systèmes hétérogènes [12]. La communication est toujours localisée dans le cadre d’un protocole de la couche application. WebService utilise HTTP comme une protocole de communication. Le protocole HTTP C’est un protocole de communication client-serveur. Les requêtes HTTP effectuent sur le serveur disposent d’une méthode qui est une commande qui a pour rôle de spécifier l’action qu’on veut exécuter sur les ressources du serveur. API REST Une API REST peut être modélisée comme une boite noire qui contient des fonctions chacune nous permet de gérer des ressources sur le serveur. Chaque fonction est distinguée par une route et une méthode HTTP. Ainsi, pour accéder au service d’une fonction on envoie une requête HTTP avec sa méthode et sur sa route [13]. Exemples Le tableau suivant présente un exemple d’API de gestion d’un groupe. Rapport de Projet de Fin d’études 1
  • 72. Annexe A Table 1 – Exemple d’une API REST (Méthodes HTTP, routes et descriptions) Méthode HTTP Route Description Type de l’opération GET /group/list Récupérer la liste des groupes Lecture seule GET /group/info/1 Récupérer les infor- mations relatives au groupe ayant l’ID 1 Lecture seule POST /group/create Ajouter un nouveau groupe Ecriture PUT /group/update/1 Mise à jour le groupe qui possède l’identi- fiant 1 Ecriture DELLETE /goup/1/delete Supprimer le client dont l’identifiant est égal à 1 Ecriture Exemple : La figure ci-dessus présente un exemple d’une requête GET et réponse du serveur en utilisant Postman. Figure A1 – Exemple d’une requête GET et réponse du serveur WebSocket : Une WebSocket permet l’échange données entre un client et un serveur de manière asynchrone, bidirectionnelle en mode full duplex utilisant une Rapport de Projet de Fin d’études 2
  • 73. Annexe A connexion TCP. Les WebSockets sont typiquement utilisées pour envoyer de petits messages. La spécification du protocole WebSocket est définie dans la RFC 6455, publiée en décembre 2011. Les WebSockets sont plus efficaces et sont plus performantes que les autres solutions : • Elles requièrent moins de bande passante car elles ne requièrent pas d’en-tête dans chaque message. • La latence est réduite. • Elles permettent de mettre en place des solutions quasi temps réel pour recevoir des données. Les cas d’utilisation des WebSockets sont nombreux : elles sont utilisables dès que des données doivent être envoyées du serveur vers le ou les clients[14]. Rapport de Projet de Fin d’études 3
  • 74. Annexe B RabbitMQ RabbitMQ est un message broker très complet et robuste, son rôle est de transporter et router ensembles des messages à partir de les Publishers vers les Consumers. Ce broker utiliser les exchanges et bindings pour connaitre s’il doit délivrer, ou non le message dans la queue. Fonctionnalité du broker : Voici comment le broker se fonctionne : Dans un exchange, le Publisher va envoyer un message, l’exchange va, en fonc- tion du binding, router le message vers la ou les queues. Enfin, un Consumer va consommer les messages [15]. Comme, présente la figure ci-dessus. Figure B1 – Architecture de système rabbitMQ Dans ce stade, nous allons donc détailler les éléments qui composent le broker. • Le message : Le message est comme une requête HTTP, il contient des attributs et un payload. Parmi les attributs du que vous pouvez ajouter sont les headers. • Les Bindings : Rapport de Projet de Fin d’études 4
  • 75. Annexe B Les bindings, ce sont les règles que les exchanges utilisent pour détermi- ner à quelle queue il faut délivrer le message. Les différentes configura- tions peuvent utiliser la routing key (direct/topic exchanges) ainsi que les headers (header exchanges). Dans le cas des exchanges “fanout”, les queues n’ont qu’à être blindées pour recevoir le message [15]. • Les exchanges : Un exchange est un routeur de message. Il existe plusieurs types de routages, dans le cas de broker rabbitMQ sont définis comme un type d’exchange : – L’exchange fanout : C’est le plus simple. Il délivre le message à toutes les queues bindées comme explique le schéma ci-dessous. Figure B2 – Schéma éxhange de type fanout – L’exchange direct : L’exchange direct utilise la routing_key pour autoriser le binding donc Si la routing_key du message est égale à la routing_key indiquée dans le binding alors le message sera délivré à cette queue. Le figure ci-dessous présente le principe d’exchange direct : Rapport de Projet de Fin d’études 5
  • 76. Annexe B Figure B3 – Schéma éxhange de type fanout • Les Queues : Une queue est l’endroit où sont stockés les messages. Il existe des options de configuration afin de modifier leurs comportements. Quelques options : – Durable, (stockée sur disque) la queue survivra au redémarrage du broker. Attention seuls les messages persistants survivront au redé- marrage. – Exclusive, sera utilisable sur une seule connexion et sera suppri- mée à la clôture de celle-ci. Auto-delete, la queue sera suppri- mée quand toutes les connexions sont fermées (après au moins une connexion)[15]. • Consumer : Le rôle du consumer est d’exécuter un traitement après avoir récupéré un ou plusieurs messages. Pour ce faire il va réserver (prefetching) un ou plusieurs messages depuis la queue, avant d’exécuter un traitement. Généralement si le traitement s’est correctement déroulé le consumer va acquitter le message avec suc- Rapport de Projet de Fin d’études 6
  • 77. Annexe B cès (basic.ack). En cas d’erreur le consumer peut également acquitter négativement le message (basic.nack). Si le message n’est pas acquitté, il restera à sa place dans la queue et sera re fetch un peu plus tard [16]. Rapport de Projet de Fin d’études 7
  • 78. Annexe C Tests Unitaires Pour cette partie, nous avons effectué des tests unitaires sur l’API REST ou WebSocket de l’application de quelques micro-services que nous avons développé aux cours de stage, afin d’assurer une application robuste et main- tenable. Pour faire les tests unitaires, nous utilisions une librairie nommée "ScalaTest". Nous allons vous décrirez quelques scénarios de test qui nous avons réalisé. Pour chaque test réalisé nous avons créé une fonction qui s’appelé "onI- nit()"et une fonction «clearDataBase». • La fonction "onInit()" est invoqué avant chaque méthode de test, elle se charge d’initialiser la mémoire de test, créer des instance d’objet, insérer des élément dans les collections, etc. • La fonction "clearDatabase()" est appelée après chaque méthode de test, elle supprime tout instance d’objet, vider tous les collection, etc. Figure C1 – Fonction onInit() et clearDatabase() La figure 7.14 illustre un exemple de la méthode "onInit()" et "clear- Database()" pour le teste des avis relative à chaque micro-service. Lors de lancement de test la méthode "onInit()" appelé les méthodes "createRoom", Rapport de Projet de Fin d’études 8
  • 79. Annexe C "creatRoomSupport" et "saveListMessage" que ils permettent de charger le mémoire par information à propos le Room et les messages .À la fin de test la méthode "clearDatabase()" supprime tous les information que été enregistrer dans la mémoire. Tester l’endpoint «sérialisation et désérialisations d’objet JSON» La figure ci-dessous décrit le test réalisé pour sérialiser et désérialiser un objet JSON. Figure C2 – Sérialiser et désérialiser un objet JSON Ce test consiste à : 1- Vérifier si lorsqu’en transférions objet "messageWs1" à objet JSON doit être égale à celui "messageExpectedJson". Ce dernier décrit le vrais format JSON que l’objet messageWS1 doit vérifier. Rapport de Projet de Fin d’études 9
  • 80. Annexe C 2- Vérifier que si en recevons un objet JSON "messageExpectedJson" et en applique désérialisation doit être égale à notre objet "messageWs1". Tester l’endpoint «MakeUniqueInternalMail La figure C3 illustre le test réalisé sur la méthode "makeUniqueInternal- Mail". Figure C3 – Fonction MakeUniqueInternalMail Ce test consiste à réaliser une opération de création MailIn associe à un groupe : 1- Réaliser méthode qui permet de encapsuler le nom de groupe avec le nom de domaine "ubilab.me". 2- Vérifier que le MailIn créé est unique. Tester l’endpoint «envoie et réception des message avec les Actor de AKKA» Rapport de Projet de Fin d’études 10
  • 81. Annexe C Akka est un Framework pour la construction de systèmes distribués ba- sés sur les acteurs. La philosophie adoptée en termes de tolérance de panne pour ces systèmes est « let it crash». En effet, les acteurs sont des éléments légers, qu’il est facile d’instancier et de relancer en cas de crash (du fait qu’ils ne partagent pas leur état). Pour cela, Akka impose une supervision afin de pouvoir gérer la mort prématurée d’acteurs, et ce dans une hiérarchie de su- pervision : tout nouvel acteur est supervisé par son parent. Cette supervision permet la création de systèmes qui s’auto-réparent[17]. La figure ci-dessous décrit le test réalisé pour faire envoie et réception des message avec les Actors de AKKA. Figure C4 – Envoie et réception des message avec les Actors Ce test consiste à : 1- Créer un message de type WsMobileIIn et s’appelle "mobileInMsg1" ce message contient les informations nécessaires pour créer une nouvelle Rapport de Projet de Fin d’études 11
  • 82. Annexe C chaîne de discussions. 2- Créer un Actor "wsAcorService" qui permet d’envoyer et réceptionner le message "mobileInMsg1". 3- Vérifier que notre mémoire contient la nouvelle chaîne de discussions. Rapport de Projet de Fin d’études 12
  • 83. Annexe C Rapport de Projet de Fin d’études 13