Rapport de projet de fin d"études

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 conﬁance
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.3 Projet Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
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 ﬁgures
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 notiﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 « Aﬃcher 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 « Modiﬁer 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 : Uniﬁed 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

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.

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 :

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 diﬀérentes étapes 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éﬁnition 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, enﬁn, nous avons consa-
cré la dernière pratique la méthodologie adoptée ainsi l’ensemble environnements mis en
place.

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

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].

• 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.

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 diﬀérentes micro-services) sur n’importe quelle un
serveur et accessible via un navigateur web (Chrome, Firefox, Microsoft Edge,
etc.).

– 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éciﬁcation des besoin.

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".

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.

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.

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 oﬀrir 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 suﬃsante, 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.

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.

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.

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.

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.
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.

Figure 3.3 – Digramme de rubrique administration pour le projet Laboratory
Le tableau ci-dessous décrit le scénario du cas d’utilisation « Modiﬁer logo de labora-
toire »

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.
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.

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

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.

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)

• 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
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.

• UserGroupRight : Cette entité désigne ensemble des droites associe à chaque
groupe dans laboratoire.
• 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
La figure 4.2 illustre présente le digramme de class des entités utiliser en projet Talk :

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.

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 :

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 authentiﬁé, 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ériﬁer 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

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éﬁnit la cohérence entre les diﬀé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.

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 eﬃcace
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

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 :

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

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.

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 ﬁgure 5.3 illustre l’interface qui présente la liste des groupes. Il dispose des fonc-
tionnalités qui suivent :

• 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

Figure 5.5 – Les membres du groupe
Utilisateur :
La ci-dessous présente l’interface qui présente la liste des utilisateurs. Il oﬀre des
fonctionnalités qui suivent :
• Recherche un utilisateur.
• Filtrer les utilisateurs par des ﬁltres dynamiques.
• Exporter les utilisateurs.
• Joindre l’utilisateur à un groupe.
• Mettre en pause l’utilisateur.
• Archiver l’utilisateur.

Figure 5.6 – Les membres du groupe
Les ﬁgures 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

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.

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.

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.

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.

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

Figure 5.17 – Ajout d’une catégo-
rie
Figure 5.18 – Suppression d’une
catégorie
Communication :
La ﬁgure 5.19 illustre présente l’interface qui permet de personnaliser le mail d’envoi
des d’identiﬁant 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

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

La ci-dessous présente l’interface qui permet à l’administrateur de modiﬁer 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 ﬁgure 5.15 représente l’interface principale pour Talk version web.

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.

• 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é

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.

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/ﬁche/git, der-
[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.graﬁkart.fr/formations/git/
fork-pull-request, dernière Consultation : 2018-05-18.
56

[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-
[17] “Actor akka,” https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html#
Introduction, dernière Consultation : 2018-08-28.

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.

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

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].

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. Enﬁn, un Consumer
va consommer les messages [15]. Comme, présente la ﬁgure 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 :

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 :

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-

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].

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",

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.

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»

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

Annexe C
chaîne de discussions.
2- Créer un Actor "wsAcorService" qui permet d’envoyer et réceptionner
le message "mobileInMsg1".
3- Vériﬁer que notre mémoire contient la nouvelle chaîne de discussions.

Annexe C

Rapport de projet de fin d"études

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Rapport de projet de fin d"études

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

Rapport de projet de fin d"études