Ministère de l’enseignement Supérieur et

‫العلمي والبحث العالي التعليم وزارة‬ de la recherche Scientifique

‫الجامعـة العربيـة للعلـــوم‬ Université Arabe des Sciences
‫المدرسة العليا الخاصة للمهندسيـن‬ Ecole Supérieure Privée d’Ingénieurs et
‫والدراسات التكنولوجيّة بتونس‬
des Etudes Technologiques de Tunis

Projet de Fin d’Etudes

Présenté pour obtenir le

Diplôme National d’Ingénieur

Spécialité : Génie Informatique

Système de déclaration règlementaire

Asynchrone

Elaboré par :
MDINI Mohamed Yassin

Encadrant académique : Hellali Wafa

Encadrant professionnel : LABIDI Abdessatar

Réalise au sein de MpSoft

Réalise au sein de LB Consulting

Année Universitaire 2019-2020

18،‫نهـج‬ 1002 ‫القرش األكبر‬ ‫ تونـس‬18, Rue Cyrus Legrand 1002 Tunis
‫ الهاتف‬: 023 / 71 335 073 71 336 Tél : 71 336 023 / 71 335 073
 Dédicaces

Nous dédions ce travail,

A nos très chers parents Abderrahman & Samira qui nous ont toujours
soutenus, encouragés en approuvant nos choix et nos décisions.

A nos sœur et frère Hiba & Kacem qui ont toujours été à nos côtés
pour nous conseiller.

A nos amis les plus sincères qui sauront se reconnaître.

A nos encadrants et professeurs qui ont été toujours présents et qui nous
ont aidés à réaliser ce travail.

Qu’ils veuillent trouver ici, l’expression de nos profonds respects.

 Remerciement

Nous tenons tout d’abord à exprimer nos profondes gratitudes à toutes les
personnes qui ont contribué à notre succès et à nos encadrants,

A Monsieur LABIDI Abdessatar, Responsable production et responsable

de notre sujet qui nous a toujours aidées en cas de complication et qui était
pré- sent pour nous jusqu’à la fin.

A Madame Hellali wafa, notre enseignante et encadrante du sujet de fin

d’études à l’UAS qui n’a cessé de nous prodiguer tout au long de cette
période et nous a conseillées sur l’orientation que celui-ci devait prendre.

Nous adressons aussi nos vifs remerciements pour toute l’équipe MpSoft
pour leur accueil et leur esprit d’équipe.
 Table des matières
INTRODUCTION GENERALE .............................................................................................................................. 6
CHAPITRE I : CONTEXTE GENERAL DU PROJET .................................................................................................. 8
1. INTRODUCTION .............................................................................................................................. 9
2. PRESENTATION DE L’ENTREPRISE ........................................................................................... 9
3. PRESENTATION DU PROJET ...................................................................................................... 10
3.1 ETUDE DE L’EXISTANT ........................................................................................................................ 10
3.2 PROBLEMATIQUE ................................................................................................................................ 11
3.3 SOLUTIONS PROPOSEES ...................................................................................................................... 12
3.4 ARCHITECTURE REST ....................................................................................................................... 12
3.5 AUTHENTIFICATION DU LOGICIEL ..................................................................................................... 13
3.6 SERVICE DES OPERATIONS DES VERSEMENTS .................................................................................... 13
a. Description .............................................................................................................................................. 13
b. Donnée en entrée .................................................................................................................................... 14
c. Donnée en sortie...................................................................................................................................... 16
3.7 SERVICES DES OPERATIONS DE CESSION BBE ................................................................................... 17
a. Donnée en entrée .................................................................................................................................... 17
b. Données en sortie .................................................................................................................................... 19
3.8 SERVICE D’ALIMENTATION DES OPERATIONS DES AUTORISATIONS DES SORTIE ............................. 19
a. Données en entrée ................................................................................................................................... 19
b. Données en sortie .................................................................................................................................... 21
3.9 SERVICE DES OPERATIONS DE TRANSFERT DES DEVISES ................................................................... 21
a. Données en entrée ................................................................................................................................... 21
b. Données en sortie .................................................................................................................................... 22

4. PLANIFICATION DES TACHES DU PROJET ............................................................................ 23

5. ARCHITECTURE DU PROJET ..................................................................................................... 23
6. METHODOLOGIE DE DEVELOPPEMENT ................................................................................ 24
A. CYCLE DE VIE : MODELE EN V ............................................................................................................... 24
B. PLANIFICATION DU TRAVAIL .................................................................................................................. 26
7. CONCLUSION................................................................................................................................. 26
CHAPITRE II : SPECIFICATION ET ETUDE DES BESOINS ..................................................................................... 27
INTRODUCTION ............................................................................................................................ 28
OUTILS ET METHODES DE MODELISATION .......................................................................... 28
SPECIFICATION DES BESOINS FONCTIONNELS : ................................................................. 28
SPECIFICATION DES BESOINS NON FONCTIONNELS .......................................................... 29
MODELISATION DES BESOINS : ................................................................................................ 30
5.1 PRÉSENTATION D’UML ...................................................................................................................... 30
1
 5.2 IDENTIFICATION DES ACTEURS........................................................................................................... 30
5.3 LES DIAGRAMMES DES CAS D’UTILISATIONS ..................................................................................... 31
a. Diagramme de cas d’utilisations générale ............................................................................................... 31
b. Diagramme de cas d’utilisations<<API Producer>> ............................................................................. 33
c. Diagramme de cas d’utilisations<<API Consumer>> ........................................................................... 34

CONCLUSION................................................................................................................................. 37
CHAPITRE III : CONCEPTION ............................................................................................................................ 38
1. INTRODUCTION ............................................................................................................................ 39
2. ARCHITECTURE DE L’APPLICATION ...................................................................................... 39
3. OUTIL DE CONCEPTION STARUML : ....................................................................................... 41
4. DIAGRAMMES DE SEQUENCES ................................................................................................. 42
4.1 DIAGRAMME DE SEQUENCES DE « S’AUTHENTIFIER »....................................................................... 43
4.2 DIAGRAMME DE SEQUENCES DE « PRODUIRE DES DONNEES POUR KAFKA » .................................... 43
4.3 DIAGRAMME DE SEQUENCES DE « CONSOMMER DES DONNEES DE KAFKA » .................................... 44
4.4 DIAGRAMME DE SEQUENCES DE « AJOUTER PARAMETRE DE MAPPAGE » ...................................... 45
4.5 DIAGRAMME DE SEQUENCES DE « EDIT PARAMETRE DE MAPPAGE................................................. 46
5. DIAGRAMME DES CLASSES ....................................................................................................... 47
6. CONCLUSION................................................................................................................................. 48
CHAPITRE IV : REALISATION ........................................................................................................................... 49
1. INTRODUCTION ............................................................................................................................ 50
2. LANGAGES ET OUTILS DE DEVELOPPEMENT : .................................................................... 50
2.1 FRAMEWORK SPRING ......................................................................................................................... 50
3.10 BOOTSTRAP ......................................................................................................................................... 50
3. ENVIRONNEMENT MATERIEL : ................................................................................................ 50
4. ENVIRONNEMENT LOGICIEL .................................................................................................... 51
4.1 ECLIPSE ............................................................................................................................................... 51
4.2 APACHE KAFKA .................................................................................................................................. 51
4.3 STARUML ........................................................................................................................................... 51
4.4 ORACLE DATABASE ............................................................................................................................ 52
5. INTERFACES DE SYSTEME......................................................................................................... 52
5.1. KAFKA ................................................................................................................................................. 52
5.2. API PRODUCER ................................................................................................................................... 53
5.3. API CONSUMER .................................................................................................................................. 56
5.4. MPHANNIBAL ................................................................................................................................. 59
a. Interface « Authentification » .................................................................................................................. 59
b. Interface « Consulter liste des opération » .............................................................................................. 60
c. Interface « ajouter une opération » ......................................................................................................... 61
d. Interface « éditer une opération » ........................................................................................................... 61
e. Interface « Consulter liste des Mappage » ............................................................................................... 62

2
f. Ajouter un mappage ................................................................................................................................ 63
g. Interface « Consulter liste des Web Service »........................................................................................... 64
h. Ajouter un web service ............................................................................................................................. 65
i. Web service de MPHANNIBAL .................................................................................................................. 66
j. Mapping ................................................................................................................................................... 67
k. Invocation de web service de Hannibal .................................................................................................... 69

6. CONCLUSION................................................................................................................................. 69
CONCLUSION GENERALE ................................................................................................................................ 70
BIBLIOGRAPHIE .............................................................................................................................................. 72

3
 Liste des Figures

Figure 1: Logo de MpSoft ....................................................................................................................... 9

Figure 2: schéma descriptif de l’architecture REST .............................................................................. 13
Figure 3: Schéma architecture ............................................................................................................... 24
Figure 4: Modèle du cycle de vie en V.................................................................................................. 25
Figure 5: Diagramme de cas d’utilisations générale ............................................................................. 32
Figure 6: Diagramme de cas d’utilisations<<API Producer>> ............................................................. 33
Figure 7: Diagramme de cas d’utilisations<<API Consumer>> ........................................................... 34
Figure 8: Diagramme de cas d’utilisations<<MPHANNIBAL>> ........................................................ 35
Figure 9: Diagramme de cas d’utilisations<<Agent>> ......................................................................... 36
Figure 10: Modèle MVC ....................................................................................................................... 40
Figure 11: Diagramme de séquences de « S’authentifier » ................................................................... 43
Figure 12: Diagramme de séquences de « Produire des données pour kafka » ..................................... 44
Figure 13: Diagramme de séquences de « Consommer des données de kafka » .................................. 45
Figure 14: Diagramme de séquences de « Ajouter Paramètre de Mappage » ....................................... 46
Figure 15: Diagramme de séquences de « Edit Paramètre de Mappage................................................ 47
Figure 16: Diagramme de classes .......................................................................................................... 48
Figure 17: logo de spring framework .................................................................................................... 50
Figure 18: Création de topic .................................................................................................................. 52
Figure 19: Création de Producer ........................................................................................................... 53
Figure 20: Création de consumer .......................................................................................................... 53
Figure 21: « Producer » configuration................................................................................................... 54
Figure 22: Méthode d’envoyé les données à Kafka .............................................................................. 54
Figure 23: Création de log personnalisé pour l'API Producer ............................................................... 55
Figure 24: JAR exportation ................................................................................................................... 56
Figure 25: « Consumer » configuration................................................................................................. 57
Figure 26: Principe de la méthode « runConsumer » ............................................................................ 58
Figure 27: Appel du web service ........................................................................................................... 58
Figure 28: Log Consumer...................................................................................................................... 59
Figure 29: Interface « Authentification » ............................................................................................. 60
Figure 30: Interface « Consulter liste des opérations » ......................................................................... 60
Figure 31: Interface « ajouter une opération » ...................................................................................... 61
Figure 32: Interface éditer une opération .............................................................................................. 61
Figure 33: Interface « Consulter liste des Mappage » ........................................................................... 62
Figure 34: Interface « ajouter un mappage » ......................................................................................... 63
Figure 35: Interface « Consulter liste des Web Service » ..................................................................... 64
Figure 36: Interface ajouter un web service .......................................................................................... 65
Figure 37: Web service MPHANNIBAL .............................................................................................. 66
Figure 38: Méthode de mappage ........................................................................................................... 67
Figure 39: Test de web service .............................................................................................................. 68
Figure 40: méthode d'invocation de web service .................................................................................. 69

4
 Liste des tableaux
Tableau 1: Exemple authentification d'un web service ............................................................ 13
Tableau 2: Donnée d'entrée de versement web service ............................................................ 15
Tableau 3: Exemple de donnée d’entrée de web service versement ........................................ 16
Tableau 4: donnée de sortie de web service de versement ....................................................... 17
Tableau 5 : Exemple de donnée de sortie ................................................................................. 17
Tableau 6: Donnée d'entrée de Service des opérations de cession des BBE ............................ 19
Tableau 7: Donnée en sortie de Service des opérations de cession des BBE .......................... 19
Tableau 8: Donnée d'entrée Service d’alimentation des autorisations de service .................... 20
Tableau 9: Donnée sortie Service d’alimentation des autorisations de service ....................... 21
Tableau 10: Donnée d'entrée de Service des opérations de transfert des devises .................... 22
Tableau 11: Donnée de sortie de Service des opérations de transfert des devises ................... 23
Tableau 12: Description de diagramme de cas d’utilisations<<API Producer>> .................... 33
Tableau 13: Description de diagramme de cas d’utilisations<<API Consumer>> .................. 34
Tableau 14: Description de diagramme de cas d’utilisations<<MPHANNIBAL>> ............... 35
Tableau 15: Description de diagramme de cas d’utilisations<<Agent>> ................................ 37

5
 Introduction Générale

Le marché des technologies a connu une évolution énorme ces dernières années et avec
l'intégration de l'internet il y a eu des changements sur la façon et la rapidité d'accès aux
informations. Plusieurs secteurs se sont adaptés à ce changement et encore plus ont vu le jour
pour satisfaire ces nouveaux clients. Les banques représentent l'un des domaines qui
connaissent un nombre énorme de client et qui souffrent pour les satisfaire.

Ils doivent alors proposer leurs services d'une façon plus rapide et sécurisé mais aussi à
distance afin de pouvoir éviter la congestion dans les agences. Les entreprises informatiques
voient dans le Big Data, une opportunité de trouver des nouveaux leviers de compétitivité
pour améliorer leur relation avec ses clients. MpSoft l’un des entreprises les plus connus qui
cherche toujours à répondre aux besoins de ces clients financières ( Poste , banques …)

Afin de valider un diplôme d’ingénieur de l’UAS spécialisé en informatique , il est nécessaire

de terminer la formation par un projet de fin d’étude ( PFE). J’ai choisi d’effectuer mon PFE à
MPSoft. L’objectif de ce projet de gagner le maximum de temps de transfert et de gestion afin
de satisfaire le besoin du Banque Centrale ainsi que réaliser la première application en Tunisie
qui utilise la technologie Kafka.

Le présent rapport est structuré en quatre chapitres à travers lesquels on décrit les étapes de
réalisation du projet selon la méthodologie le modèle en V.

Le premier chapitre « cadre de projet » met le projet dans son contexte en présentant le cadre
général du projet, l'étude de l'existant ainsi que le choix de la méthodologie adoptée pour la
gestion de projet.

Le deuxième chapitre « Spécification des besoins » sera consacré à l'analyse des besoins
fonctionnels et non fonctionnels. En modélisant les besoins des utilisateurs via les
diagrammes de cas d’utilisation.

6
Le troisième chapitre « Conception » est consacré pour l'analyse qui est composée d'une vue
statique illustrée par des diagrammes de classes participantes et une vue dynamique présentée
par des diagrammes de séquences.

Le quatrième chapitre « Réalisation » décrit le travail réalisé en présentant l'ensemble des

outils utilisés dans le projet ainsi que les différentes interfaces de l’application.

7
Chapitre I : Contexte général du projet

8
 1. Introduction
Au cours de ce chapitre nous mettons notre travail dans son contexte. Nous allons présenter
l’organisme d’accueil, ainsi le cadre général du projet et l’état de l’existant, enfin nous décrivons
notre démarche en argumentant le choix de la méthode de modélisation

2. Présentation de l’entreprise

Ayant atteint la troisième année ingénierie informatique à Université Arabe des Sciences,
un sujet de fin d’études nous est demandé d’accomplir.
Notre choix s’est rapporté à Système de déclaration règlementaire Asynchrone.

Après de nombreuses recherches et demandes de stages, nous avons réussi à obtenir l’accord
des responsables de la société Manager Partner Software (MpSoft).

MpSoft est une société de Services, de conseil et d’ingénierie Informatique, créée autour d’un
noyau de compétences ayant une grande expérience dans le domaine des activités bancaires
et des nouvelles techniques, spécialisée dans la mise en œuvre de systèmes d’information des
institutions financières (Banques, banques postales et assurances).

Figure 1: Logo de MpSoft

Parmi les nombreuses applications crées par cette société dans ce secteur, MpBank qui est un
des rares global Banking orienté client destinée principalement aux établissements bancaires.
MpSoft propose un nombre des webservices qui couvrant l'ensemble des opérations de
l'activité bancaire. C'est dans ce cadre que s'inscrit ce projet de fin d 'études effectué au sein
de la société MpSoft dont l'objectif est de mettre en place un Système de déclaration
règlementaire Asynchrone basées sur les technologies de big data.

9
La mission de MpSoft :

✓ Conseil en management et gestion de la performance d'entreprise : Business

Intelligence
✓ Conseil et accompagnement en organisation et mise en place des processus d’activité
financière, bancaire et postale
✓ Consulting en Finance Islamique
✓ Editeur de la solution Business Intelligence Bancaire BankAnalytiX
✓ Editeur de la suite des applications bancaires MpBank Software
✓ Editeur de la suite des applications Postales MpPost Financial

3. Présentation du projet
3.1 Etude de l’existant

L’étude de l’existant est une étape primordiale dans le parcours de réalisation de notre
application. En fait, elle nous a permis de présenter les résultats de l’étude existante, de point
de vue présentation, description et critiques.

Cette étape constitue une phase de diagnostic qui vise à étudier l’état actuel afin de
chercher une amélioration de l’existant. Pour ce faire, nous procédons à une étude du mode
actuel tout en dégageant les défaillances remarquées enfin nous exposons la solution
proposée.

Dans une époque où la rapidité de chercher et exploiter les informations devenu le

moteur pour gagner les clients et renforcer leur confiance, dans ce contexte.

Ainsi pour l’étude de l’existant nous avons combiné les différentes méthodes qui sont :

✓ Exploitation de toutes documentations relatives au transfert des données des

banques

✓ Recueillir les informations des différents interlocuteurs dans le domaine de

notre potentiels application : entretiens et questionnaire

✓ Analyse et exploitation de documents techniques tels que catalogues

fournisseurs et données statistiques

10
L’état actuel du site se caractérise par :

✓ Le manque d’un moyen fiable permettant d’interfacer avec différentes plateformes

(secteurs Banques)
✓ La perte du temps pour la recherche d’une information

✓ L’absence d’une solution informatique pour couvrir le problème décrit au-dessus.

3.2 Problématique

Dans nos jours, on rencontre plusieurs difficultés liées aux systèmes d'information de
l'entreprise. Le problème de Global Banking qu'il est un système qui nécessite une haute
performance de système en termes de rapidité, sécurité et fiabilité afin de récupérer et diffuser
les informations.

La CTAF a eu une entrevue avec un groupe d’experts de l’Union européenne dans le cadre du
programme régional de lutte contre le terrorisme financé par l’instrument contribuant à la
stabilité et à la paix (IcSP) qui a pour vocation d’appuyer les initiatives en matière de sécurité
et les actions de consolidation de la paix dans les pays partenaires de l’Union Européenne.

La CTAF a également reçu, dans le cadre du programme de l’Union Européenne

d’appui pour la réforme et la modernisation du secteur de la sécurité, des experts européens
pour examiner les possibilités de bénéficier dudit programme qui cible le renforcement des
capacités des services de renseignements impliqués dans la lutte contre le blanchiment
d’argent et le financement du terrorisme. C’est dans ce cadre que la CTAF a pu obtenir le
financement de la mise en place de la plateforme « Hannibal » pour le suivi des flux de
devises en espèces à travers le territoire tunisien.

Dans ce cadre, une implémentation d’un client REST de l’API HANNIBAL à destination des
banques et de poste pour s’interfacer avec la plateforme HANNIBAL est devenu impérieux et
urgent. L’objectif est de spécifier les services de l’API afin de permettre d’automatiser
l’alimentation des versements des montants en devise, opérations de cession des BBE, les
autorisations de sorties et les opérations des transferts.

11
Un système fiable, sécurisé et rapide doit être mis en place pour suivre les opérations
bancaires et éviter des cas de fraude et blanchiment d’argent dans le territoire tunisien

3.3 Solutions proposées

Développer un client MPHANNIBAL à destination des banques et de poste pour s’interfacer

avec la plateforme HANNIBAL en basant sur la technologie de Plateforme de diffusion
distribuée de notre choix pour augmenter la performance et la rapidité d’envoyé de notre
donnée et de but de tracer les actions qui passe par ce système.

Dans L’objectif est de spécifier les services de l’API afin de permettre d’automatiser
l’alimentation des versements des montants en devise, opérations de cession des BBE, les
autorisations de sorties et les opérations des transferts en basant sur l’architecture REST et
d’une structure bien déterminer des fichier JSON.

3.4 Architecture REST

Les API REST st un style d'architecture logicielle définissant un ensemble de contraintes à

utiliser pour créer des services web. Les services web conformes au style d'architecture
REST, aussi appelés services web RESTful, établissent une interopérabilité entre les
ordinateurs sur Internet.

Les API REST sont basées sur HTTP, qui signifie HyperText Transfer Protocol. C’est un
protocole qui définit la communication entre les différents systèmes. L’échange est basé sur
des requêtes client et serveur.

Le choix du REST justifié par son extensibilité et l’aptitude de l’intégré dans des systèmes
existants sans être susceptible de la diversité technologique.

Ci-dessous un schéma descriptif de l’architecture REST :

12
 Figure 2: schéma descriptif de l’architecture REST

3.5 Authentification du logiciel

L’usage des services HANNIBAL nécessite une authentification « Basic Auth » à chaque
requête, et en cas d’erreur d’authentification (code http 401) le logiciel doit renvoyer la
requête de nouveau.

L’authentification se fait par l’entête HTTP Autorisation avec un Encodage base64.

Ci-dessous un exemple d’entête d’une requête authentifiée :

Entête d’une requête authentifiée d’un webservice HANNIBAL

….
Host: [Link]
Content-Type: application/json
Authorization: Basic dXNlcjE6bW90cGFzcw==
cache-control: no-cache

Tableau 1: Exemple authentification d'un web service

Dans l’exemple ”Basic dXNlcjE6bW90cGFzcw==” est l’encodage base64 de la

concaténation login/password suivante : user1:motpass.

3.6 Service des opérations des versements

a. Description

Ce service permet d’alimenter la plateforme HANNIBAL par les versements des montants
déclarés à la Douane. Les utilisateurs de cet API sont notamment les systèmes bancaires et
les systèmes de poste.

13
Le service est exposé via web en utilisant REST. L’exploitation de ce service se passe par
l’envoie d’une requête POST à la ressource suivante:
[Link]

b. Donnée en entrée

Les données en entrée sont encapsulées dans une structure de données : [Versement] définie
dans le tableau suivant:

Nom fonctionnel Champs de webservice Type Exigence

N° versement “numVersement” chaîne de caractères *
Date de versement “dateVersement” chaîne de caractères Norme :
* ISO-8601
Nom “nom” chaîne de caractères *
Prénom “prenom” chaîne de caractères *
N° passeport “numPasseport” chaîne de caractères Obligatoire si pas de
CIN/Carte séjour.
N° CIN “numCIN” chaîne de caractères Obligatoire si pas de
passeport.
N° carte de séjour “numSejour” chaîne de caractères Obligatoire si pas de
passeport, résident et
nationalité non
Tunisienne.
N° du compte “numCompte” chaîne de caractères * Format IBAN

Devise de compte “deviseCompte” chaîne de caractères *

Titulaire du compte “titulaireCompte” chaîne de caractères *

Nationalité “nationalite” chaîne de caractères * Norme utilisée par la
BCT
N° de la déclaration de “numDD” chaîne de caractères *
douane
Pays de résidence “paysResidence” chaîne de caractères * Norme utilisée par la
BCT
Banque “banque” chaîne de caractères *
Agence “agence” chaîne de caractères *

14
 Agent “agent” chaîne de caractères
Equivalent en TND “equivalentTND” Numérique *
Code de devise “codeDevise” chaîne de caractères * Norme : ISO-4217
Montant de devise “montantDevise” Numérique *
Taux de change “tauxChange” Numérique *
Coupures des devises “coupuresDevise” chaîne de caractères *

Tableau 2: Donnée d'entrée de versement web service

Ci-dessous un exemple de requête :

15
 Exemple de requête de service d’alimentation des versements des devises
POST /api/banques/versements HTTP/1.1
Host: [Link]
Content-Type: application/json
Authorization: Basic ...
cache-control: no-cache
{
"numVersement": "01001VR1010211",
"dateVersement": "2019-01-21T[Link].924Z",
"nom": "Ben Foulen",
"prenom": "Foulen",
"numPasseport": "",
"numCIN": "12345678",
"numSejour": "",
"numCompte": "123456789012345678901234",
"deviseCompte" : "EUR",
"titulaireCompte": "Mohamed Ben Foulen",
"nationalite": "TN",
"numDD": "DD7001554",
"paysResidence": "TN",
"banque": "01",
"agence": "001",
"agent": "Mohamed Salah",
"equivalentTND": 17000
}
Tableau 3: Exemple de donnée d’entrée de web service versement

c. Donnée en sortie

Les données en sortie sont distinguées en deux cas : succès de la requête ou son échec. Un
code http serait indiqué dans l’entête de la réponse.

Ci-dessous le format du message de réponse en cas de succès.

16
 Nom fonctionnel Champs de Type Valeurs possibles
réponse
Message de réponse “message” chaîne de caractères Un message textuel décrit le
résultat de réponse

Contenu de réponse “content” chaîne de caractères Contient le N° Versement en cas

de succès.
Tableau 4: donnée de sortie de web service de versement

Exemple de réponse
Status Code: 201Created
Content-Type: application/json
Date: Thu, 24 Jan 2019 [Link] GMT
Content-Length: 24
{
"message": "Versement bien crée",
"content": "01001VR1010211"

Tableau 5 : Exemple de donnée de sortie

3.7 Services des opérations de cession BBE

a. Donnée en entrée

Les données en entrée sont encapsulées dans une structure de données : [CessionBBE]
définie dans le tableau suivant :

17
Nom fonctionnel Champs de webservice Type Exigence
N° Cession “numCession” chaîne de caractères *
Date de cession “dateCession” chaîne de caractères Norme :
* ISO-8601
Nom “nom” chaîne de caractères *

Prénom “prenom” chaîne de caractères *

N° passeport “numPasseport” chaîne de caractères Obligatoire si pas de

CIN/Carte séjour.
N° CIN “numCIN” chaîne de caractères Obligatoire si pas de
passeport.
N° carte de séjour “numSejour” chaîne de caractères Obligatoire si pas de
passeport, résident et
nationalité non Tunisienne.
N° du compte “numCompte” chaîne de caractères Format IBAN

Devise de compte “deviseCompte” chaîne de caractères Norme : ISO-4217

Obligatoire s’il ya un numéro
de compte
Titulaire du compte “titulaireCompte” chaîne de caractères Obligatoire s’il ya un numéro
de compte
Nationalité “nationalite” chaîne de caractères * Norme utilisée par la BCT
Pays de résidence “paysResidence” chaîne de caractères * Norme utilisée par la BCT
N° de la déclaration de “numDD” chaîne de caractères
douane

Banque “banque” chaîne de caractères

*
Agence “agence” chaîne de caractères *

Agent “agent” chaîne de caractères

Equivalent en TND “equivalentTND” Numérique

*

18
 Code de devise “codeDevise” chaîne de caractères Norme : ISO-4217
*
Montant de devise “montantDevise” Numérique
*
Taux de change “tauxChange” Numérique
*
Coupures des devises “coupuresDevise” chaîne de caractères

Tableau 6: Donnée d'entrée de Service des opérations de cession des BBE

b. Données en sortie

Les données en sortie sont distinguées en deux cas: succès de requête ou échec. Un code http
sera indiqué dans l’entête de la réponse.

Ci-dessous le format de message de réponse.

Nom fonctionnel Champs de Type Valeurs possibles

réponse
Message de réponse “message” chaîne de caractères Un message textuel décrit le
résultat de réponse
Contenu de réponse “content” chaîne de caractères Contient le N° Cession en cas de
succès.
Tableau 7: Donnée en sortie de Service des opérations de cession des BBE

3.8Service d’alimentation des opérations des autorisations des

sortie

a. Données en entrée
Les données en entrée sont encapsulées dans une structure de données [AutorisationSortie]
définie dans le tableau suivant :

Nom fonctionnel Champs de Type Exigence

webservice
N° d’autorisation de sortie “numAS” chaîne de caractères *

19
 Date d’autorisation de “dateAS” chaîne de caractères Norme :
sortie * ISO-8601
Date d’échéance “dateEcheance” chaîne de caractères Norme :
* ISO-8601
Nom “nom” chaîne de caractères *
Prénom “prenom” chaîne de caractères *
N° passeport “numPasseport” chaîne de caractères Obligatoire si pas de
CIN/Carte séjour
N° CIN “numCIN” chaîne de caractères Obligatoire si pas de
passeport
N° carte de séjour “numSejour” chaîne de caractères Obligatoire si pas de
passeport, résident et
nationalité non Tunisienne
N° du compte “numCompte” chaîne de caractères * Format IBAN
Titulaire du compte “titulaireCompte” chaîne de caractères *
Devise de compte “deviseCompte” chaîne de caractères * Norme :ISO-4217
Pays de résidence “paysResidence” chaîne de caractères * Norme utilisée par la BCT
Nationalité “nationalite” chaîne de caractères * Norme utilisée par la BCT
Profession “profession” chaîne de caractères
Nombre des accompagnés “accompagne” Numérique
Pays de destination “destination” chaîne de caractères * Norme utilisée par la BCT
Motif du transfert “motifTransfert” chaîne de caractères
Origine des fonds “origineFonds” chaîne de caractères
Banque “banque” chaîne de caractères *
Agence “agence” chaîne de caractères *
Agent de banque “agent” chaîne de caractères
Equivalent en TND “equivalentTND” Numérique *
Code de devise “codeDevise” chaîne de caractères * Norme : ISO-4217
Montant de devise “montantDevise” Numérique *
Taux de change “tauxChange” Numérique *
Coupures des devises “coupuresDevise” chaîne de caractères
Tableau 8: Donnée d'entrée Service d’alimentation des autorisations de service
20
 b. Données en sortie
Les données en sortie sont distinguées en deux cas : succès de requête ou échec. Un code http
sera indiqué dans l’entête de la réponse.

Ci-dessous le format de message de réponse en cas de succès.

Nom fonctionnel Champs de Type Valeurs possibles

réponse
Message de réponse “message” chaîne de caractères Un message textuel décrit le
résultat de réponse
Contenu de réponse “content” chaîne de caractères Contient le N° de l’autorisation de
sortie en cas de succès.
Tableau 9: Donnée sortie Service d’alimentation des autorisations de service

3.9 Service des opérations de transfert des devises

a. Données en entrée

Les données en entrée sont encapsulées dans une structure de données : [Transfert] définie
dans le tableau suivant :

Nom fonctionnel Champs de webservice Type Exigence

N° de transfert “numTransfert” chaîne de caractères *
Date de transfert “dateTransfert” chaîne de caractères * Norme :
ISO-8601
Nom de l’expéditeur “nomExpediteur” chaîne de caractères *
Prénom de l’expéditeur “prenomExpediteur” chaîne de caractères *
N° passeport “numPasseport” chaîne de caractères Obligatoire si pas
de CIN/Carte
séjour
N° CIN “numCIN” chaîne de caractères Obligatoire si pas
de passeport
N° carte de séjour “numSejour” chaîne de caractères Obligatoire si pas
de passeport,
résident et
21
 nationalité non
Tunisienne
Pays de résidence de “paysResidenceExpediteur” chaîne de caractères * Norme utilisée
l’expéditeur par la BCT
Nationalité de l’expéditeur “nationaliteExpediteur” chaîne de caractères * Norme utilisée
par la BCT
N° Compte de l’expéditeur “numCompteExpediteur” chaîne de caractères * Format IBAN
Devise de compte de “deviseCompteExpediteur” chaîne de caractères * Norme : ISO-4217
l’expéditeur
Titulaire compte de l’expéditeur “titulaireCompteExpediteur” chaîne de caractères *
N° Compte de destinataire “numCompteDestinataire” chaîne de caractères * Format IBAN
Titulaire compte de destinataire “titulaireCompteDestinataire” chaîne de caractères *

Banque “banque” chaîne de caractères *

Agence “agence” chaîne de caractères *
Agent de banque “agent” chaîne de caractères
Equivalent en TND “equivalentTND” Numérique *
Code de devise “codeDevise” chaîne de caractères * Norme : ISO-4217
Montant de devise “montantDevise” Numérique *
Taux de change “tauxChange” Numérique *
Tableau 10: Donnée d'entrée de Service des opérations de transfert des devises

b. Données en sortie
Les données en sortie sont distinguées en deux cas : succès de requête ou échec. Un code http
sera indiqué dans l’entête de la réponse.

Ci-dessous le format de message de réponse en cas de succès.

22
 Nom fonctionnel Champs de Type Valeurs possibles
réponse
Message de réponse “message” chaîne de caractères Un message textuel décrit le
résultat de réponse
Contenu de réponse “content” chaîne de caractères Contient le N° de transfert en cas
de succès.
Tableau 11: Donnée de sortie de Service des opérations de transfert des devises

4. Planification des tâches du projet

✓ Installation et configuration d’un broker : cette étape nécessite la recherche des

différents brokers qui existent et de choisir la plus adaptable à notre solution.

✓ Création d’un fichier JAR : lors de cette étape on va chercher la bonne pratique de
création un fichier jar et comment structurer les données selon besoin dynamiquement.

✓ Création d’un client webservice interne : dans cette étape nous allons créer une
application qui consomme les données existantes dans le broker et qui cherche la
bonne création d’un client web service

✓ Création de client web service MPHANNIBAL : dans cette étape on va créer des web
services internes et invoquer des web service simultanément.

5. Architecture du projet

Modules déjà existants : Base de données, Application Bancaire, Web services

Modules construits au sein de ce projet :

✓ API ( Producer ) : pour l’envoie des message ( Push) au Kafka Broker

23
 ✓ Kafka Cluster: inclut ZooKeeper et creation de topic

✓ API ( Consumer )

✓ MPHANNIBAL

Figure 3: Schéma architecture

6. Méthodologie de développement

a. Cycle de vie : Modèle en V

Le cycle de vie d’un logiciel désigne toutes les étapes de son développement, de sa
conception à sa réalisation. L’objectif d’un tel découpage est de permettre de définir des
intermédiaires permettant la validation du développement logiciel, c’est-à-dire la conformité
du logiciel avec les besoins exprimés et la vérification du processus de développement, ou
encore l’adéquation des méthodes mises en œuvre.

24
 L’origine de ce découpage provient du constat que les erreurs ont un coût d’autant
plus élevé qu’elles sont détectées tardivement dans le processus de réalisation.

Le modèle en V demeure actuellement le cycle de vie le plus utilisé. Il s’agit d’un modèle
en cascade dans lequel le développement des tests et des logiciels sont effectués de manière
synchrone.

Le principe de ce modèle est qu’avec toute décomposition doit être décrite la recomposition
et que toute description d’un composant est accompagnée de tests qui permettront de s’assurer
qu’il correspond à sa description.

Ceci rend explicite la préparation des dernières phases (validation-vérification) par les
premières (construction du logiciel), et permet ainsi d’éviter un écueil bien connu de la
spécification du logiciel : énoncer une propriété qu’il est impossible de la vérifier objectivement
après la réalisation.

Figure 4: Modèle du cycle de vie en V

25
 b. Planification du travail

La condition pour réussir tout projet réside dans une planification systématique orientée vers
l'objectif, établie sur la base du plan d'exécution de projet. La planification doit être réalisée
soigneusement, progressivement et conformément aux possibilités, si on veut atteindre les
objectifs du plan d'exécution de projet. La planification n'est pas un processus statique mais
dynamique. Dans la phase de planification, l'apparition de nouveaux éléments tout au long des
étapes successives nous oblige souvent à modifier les données fixées au début. Pour débuter
n’importe quel projet informatique il est nécessaire de faire une période de formation et de
documentation sur les outils, les langages et les technologies utilisés durant le période de stage.

En effet, nous allons passer à l’étape d’analyse pour identifier les besoins de notre projet
en question puis définir les spécifications fonctionnelles et non fonctionnelles. L’objectif de ces
deux phases est l’obtention d’un cahier de charge décrivant les fonctionnalités de notre application.

Puis, nous entamerons la phase de conception qui est une étape primordiale dans le cycle de
vie de toute application. Au cours de cette phase nous allons définir l’architecture de l’application,
les relations entre les éléments et élaborer les diagrammes tels que le diagramme de classes, le
diagramme d’activités et les diagrammes de séquences.

Par la suite nous attaquerons la phase de la réalisation ou nous allons utiliser les outils, les
langages et les technologies nécessaires pour développer notre application à fin qu’élaborer un
travail prêt à être testé.

Enfin, nous testerons l’application afin de valider les fonctionnalités ou de retourner en

arrière pour corriger les défauts présents.

7. Conclusion

Au cours de ce chapitre, nous avons présenté la Société MpSoft, le cadre général de

notre stage. Ensuite, nous avons précisé l’analyse de l’existant, présenté le sujet et les objectifs
à atteindre.

Dans le chapitre qui suit, nous nous intéresserons à la spécification des besoins
fonctionnels et non fonctionnels pour l’élaboration d’une telle application
26
Chapitre II : Spécification et étude des besoins

27
 Introduction
Avant de développer une application, il est nécessaire d’analyser les exigences du système. La
détermination et la compréhension des besoins sont souvent difficiles étant donné que le
développeur n’est pas forcément un connaisseur du domaine. Pour ce fait, nous devons
commencer par la modélisation des besoins des utilisateurs du système. Ceci permettra
d’identifier les fonctionnalités du système. Ce chapitre permet de déterminer les objectifs à
atteindre et permet d’analyser les besoins des utilisateurs et les contraintes à satisfaire en
développant la partie spécification par le moyen des diagrammes des cas d’utilisation.

Outils et méthodes de modélisation

Une des phases clés dans le développement d’un produit est phase de conception dans le
chapitre suivant, durant laquelle il faut : cerner les principales fonctionnalités à implanter,
réfléchir sur l’aspect structurel de l’application, et concevoir les scénarii d’utilisation de
l’application. Le but est de réduire la complexité du développement et d’avoir une vision de
différents angles de vues du système d’information.

Pour notre projet nous adaptons un cycle de vie composé de phases suivantes :

✓ Documentation et formation sur les différents technologies et outils (spring boot,

java, HTML, CSS, JavaScript…).
✓ Analyse des besoins.
✓ Spécification des besoins.
✓ Conception
✓ Réalisation
✓ Tests et maintenance
✓ Validation
✓ Exploitation

Spécification des besoins fonctionnels :

❖ Publier des données sur kafka : La première étape de notre système permet du

28
 publier les données après la validation de l’opération choisi vers Kafka.

❖ Consommer et Structurer des données de kafka : Le système doit consommer les

messages existes dans kafka et structurées ses données sous un format défini
(XML,JSon..).

❖ Mappage : Le système doit faire le mappage entre les champs reçu et leur
correspondant de champ qui nécessite d’envoyé

❖ Invocation des web service

Spécification des besoins non fonctionnels

Ce sont des exigences qui ne concernent pas spécifiquement le comportement du système
mais plutôt ils identifient des contraintes internes et externes du système.

Les principaux besoins non fonctionnels de notre application se résument dans les
points suivants :

• Performance
o L’application répond à toutes les exigences des internautes d’une manière
optimale

• Fiabilité
o Bon fonctionnement de l’application sans détection de défaillance

• Rapidité
o Le déplacement entre les pages doit être facile et rapide
o Les transactions se fait en temps réel.

• Sécurité
o Les données des utilisateurs sont sécurisées par mot de passe (longueur,
caractères spéciaux, expiration, politique de réutilisation…)
o Authentification lors de l’appel de web service

29
 o Séparation de data base des applications pour assurer la sécurité de base de
données de la poste ou la banque

Modélisation des besoins :

Dans ce niveau nous allons s’intéresser à présenter et détailler les fonctionnalités présentées
précédemment en utilisant le langage de modélisation UML (« l'Unified Modeling Language » ou
« langage de modélisation unifié ») et que nous allons l’utiliser dans ce chapitre et dans l’étape de
Conception.

5.1 Présentation d’UML

UML est un langage de modélisation graphique à base de pictogrammes. Il est apparu dans
le monde du génie logiciel, dans le cadre de la « conception orientée objet ». UML est
couramment utilisé dans les projets logiciels.

UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires
au bon développement d'un logiciel orienté objet. UML offre un standard de modélisation, pour
représenter l'architecture logicielle. Les différents éléments représentables sont :

✓ Activité d'un objet

✓ Acteurs
✓ Processus
✓ Schéma de base de données
✓ Composants logiciels
✓ Réutilisation de composants.
5.2 Identification des acteurs

Un acteur est une entité qui définit le rôle joué par un utilisateur ou par un système
qui interagit avec le système modélisé.
Nous distinguons les acteurs systèmes et humaines suivants :
Agent : est un utilisateur qui permet de gérer les différents paramètres de notre système
30
 ✓ S’authentifier.
✓ Gérer les déférents paramétrage de notre application
API Producer : est un fichier jar contient ensemble des classes et méthodes dont l’objectif de communiquer avec
la messagerie broker de notre choix :

✓ Envoi de données vers kafka

API Consumer : est une application qui joue le rôle d’un consommateur de la messagerie
broker :

✓ Consommer les données de kafka

✓ Consultation des données issues de kafka
✓ Structurer des données
✓ Appeler les web services

MPHANNIBAL : est une application indépendante, Ces fonctionnalités principales sont :

✓ Réception de données
✓ Mappage
✓ Invocation API web service
✓ Réception de données de retour
L’interfaçage ente les applications MPHANNIBAL et Hannibal est assuré à travers des APIs

5.3Les Diagrammes des cas d’utilisations

Apres l’identification des acteurs et leurs fonctionnalités nous pouvons passer à la

présentation des diagrammes de cas d’utilisation. En effet, le diagramme de cas d’utilisation
permet de définir les relations fonctionnelles entre les acteurs et l’application.

a. Diagramme de cas d’utilisations générale

Notre système se déroule d’une façon totalement automatique, aucune action manuelle est
demandée afin de gagner du temps et éviter l’erreur humaine.

A la première mise en place, une certaine configuration est obligatoire, dès que le système
est mis en route et les process tournent tous les communications sont faites entre les APIs du
système.

31
 Dans le diagramme des cas d‘utilisation (Figure 5) ont décrit toutes les fonctions de chaque
intervenant dans l’application (dans notre cas il y a que des acteurs systèmes)

Figure 5: Diagramme de cas d’utilisations générale

32
 b. Diagramme de cas d’utilisations<<API Producer>>

Figure 6: Diagramme de cas d’utilisations<<API Producer>>

La description textuelle de digramme de cas d’utilisation API Producer est représentée par le
tableau 12.

Titre API Producer

But Permettre produire les données à Kafka

Résumé -Contient les configurations nécessaires pour connecter et envoi de données

à Kafka.

-Suite à l’arrive des donnée, notre API structurée ses données sous format
précisé et produire ses données à Kafka pour stoker dans un topic spécifier.

Acteurs API Producer

Tableau 12: Description de diagramme de cas d’utilisations<<API Producer>>

33
 c. Diagramme de cas d’utilisations<<API Consumer>>

Figure 7: Diagramme de cas d’utilisations<<API Consumer>>

La description textuelle de digramme de cas d’utilisation API Consumer est représentée par le
tableau 13.

Titre API Consumer

But Interfaçage entre Kafka et MPHANNIBAL

Résumé -Contient les configurations nécessaires pour connecter et consommer les

données qui trouvent dans Kafka.

-Suite à l’arrive des données à Kafka, notre API consomme ses données et
structurer sous format précisé, après il appel le web service de
MPHANNIBAL et envoi ses données.

Acteurs API Consumer

Tableau 13: Description de diagramme de cas d’utilisations<<API Consumer>>

34
 a. Diagramme de cas d’utilisations<<MPHANNIBAL>>

Figure 8: Diagramme de cas d’utilisations<<MPHANNIBAL>>

La description textuelle de digramme de cas d’utilisation API Consumer est représentée par le
tableau 13.

Titre MPHANNIBAL

But Interfaçage avec Hannibal (déployer au sein de BCT)

Résumé -Offre à l’utilisateur des interfaces pour gérer le mappage des champs des
webservice, gérer les opérations et gérer les web services.

-Réception des données arrive de part d’API Consumer.

-Mappage des données : les clés de champs arriver correspond a des clés
reliés à l’application métier donc il faut changer ses clés avec leur
correspond du clés demander et acceptent par le Hannibal.

-Invocation de web service de Hannibal.

-lire les messages de retour de l’API Hannibal.

Acteurs MPHANNIBAL

Tableau 14: Description de diagramme de cas d’utilisations<<MPHANNIBAL>>

35
 b. Diagramme de cas d’utilisations<<Agent>

Figure 9: Diagramme de cas d’utilisations<<Agent>>

Dans le système métier chaque transaction financière ou statique fait par un utilisateur s’appelé une
opération.

La description textuelle de digramme de cas d’utilisation Agent est représentée par le tableau
15

Titre Diagramme de cas d’utilisations<<Agent>>

But Paramétrage de système MPHANNIBAL

36
 Résumé -Gérer les opérations de système, elles sont généralement des opérations
déjà existant de système métier chaque opération identifier par un code
unique et un libellé.

-Gérer le mappage des données.

-Gérer les web service : chaque web service caractériser par une adresse, un
nom et dédier à une opération.

Acteurs Agent

Tableau 15: Description de diagramme de cas d’utilisations<<Agent>>

Conclusion

Dans cette partie nous avons présenté les spécifications des besoins en insistant sur les
différents besoins fonctionnels et non fonctionnels et les différents acteurs avec la description du
chaque cas d’utilisation ainsi que les données issues de l’étude préalable et en fournissant des
informations déterminantes à modéliser le système d’information futur.

Dans le chapitre suivant, nous allons procéder à la conception du système futur et

nous allons définir les différents diagrammes nécessaires à la modélisation de notre système.

37
Chapitre III : Conception

38
 1. Introduction

L’analyse est une phase obligatoire pour le développement d’une application. Elle permet
d’organiser les fonctionnalités identifiées dans le chapitre spécification des besoins et de définir
l’architecture de notre application.

Pour la conception de notre application nous utilisons UML comme un langage de

modélisation et StarUML comme outil de conception.

Dans ce chapitre, nous allons définir l’architecture relative à notre application ainsi que
les différents diagrammes.

2. Architecture de l’application

Notre application s’appuie sur l’architecture 3 tiers ainsi que le modèle MVC sur le quel
Spring Boot est basé.

I. Architecture 3-tiers

L’architecture 3 tiers assure la séparation entre les trois couches suivantes :

✓ La couche présentation
✓ La couche métier
✓ La couche accès aux données

• La couche présentation : C’est la partie visible de l’application où l’utilisateur peut

interagir avec le système à travers l’interface graphique. En effet, la couche
présentation envoie les requêtes d’utilisateur vers la couche métier et reçoive les
résultats de traitement pour les afficher.
• La couche métier : C’est la partie de traitement qui représente la logique et les règles
fonctionnelles permettant de traiter les requêtes d’utilisateur, interagir avec la base
des données et retourner les résultats à la couche présentation.
• La couche accès aux données : Elle contient la base des données.

39
 II. Modèle MVC (Model View Controller)

Le modèle-vue-contrôleur (en anglais Model-View-Controller) est un patron d'architecture

et une méthode de conception qui organise l'interface homme-machine (IHM) d’une application
logicielle. Ce paradigme divise l'IHM en un modèle (modèle de données), une vue (présentation,
interface utilisateur) et un contrôleur (logique de contrôle, gestion des événements,
synchronisation). Cette méthode a été mise au point en 1979 par Trygve Reenskaug dans les
laboratoires de recherche Xerox PARC1.

La figure 5 représente le modèle MVC :

Figure 10: Modèle MVC

• Le Modèle :

Le modèle représente le logique métier de l'application en d’autres mots : le traitement des

données et les interactions avec la base de données... Il décrit aussi les données manipulées par
l'application tout en assurant la gestion de ces données et garantit leur intégrité. Il permet de

Définir des méthodes permettant de mettre à jour les données (insertion, suppression, changement
de valeur). Il offre aussi des méthodes pour récupérer ces données. Les résultats renvoyés par le
modèle sont indépendants de toute présentation.
40
 • La vue :

La vue correspond à l'interface avec laquelle l'utilisateur interagit. Elle n'effectue aucun
traitement. En effet, elle affiche seulement les résultats des traitements effectués par le modèle. En
plus, elle permet de présenter les résultats reçus par le modèle et de recevoir toutes les actions de
l'utilisateur (clic de souris, boutons, etc.). Ces différents événements sont envoyés au contrôleur
par la suite.

• Le contrôleur :

Le contrôleur assure la gestion des événements de synchronisation pour mettre à jour la vue
ou le modèle et les synchroniser. Il reçoit tous les événements par l’interface utilisateur et
enclenche les actions à effectuer. Le contrôleur n'effectue aucun traitement, il analyse seulement
la requête du client, appelle le modèle adéquat et renvoie la vue correspondante à la demande.

III. MVC et l’architecture 3-tiers :

La différence ente l’architecture 3-tiers et le model MVC ce que l’architecture 3-tiers assure
la séparation entre la couche accès aux données et la couche métier. Pour que MVC soit 3-tiers il
faut une couche d’abstraction entre DAO « Data Access Object » entre couche métier et la couche
accès aux données. Dans notre application Spring Boot utilise l’ORM « Object Relational
Mapping » Hibernate comme DAO. Inversement, il faut ajouter contrôleur entre la couche
présentation et la couche métier.

3. Outil de conception StarUML :

StarUML est un puissant outil de Modélisation des Systèmes informatique. Cet outil
supporte plusieurs techniques de modélisation standard : modélisation Merise (Données et
Traitements), Modélisation UML particulièrement adaptée à la logique des applications et
Modélisation des Processus Métiers dédiée aux non-informaticiens pour leur faciliter l'expression
des besoins. L'originalité d’outil tient dans la forte intégration proposée entre ces différentes
techniques. StarUML propose un environnement graphique très intuitif et très facile à aborder.

41
4. Diagrammes de séquences

Par rapport aux diagrammes de séquence système, nous allons remplacer le

système vu comme une boîte noire par un ensemble d’objets en interaction. Pour cela,
nous utilisons en core dans ce chapitre les trois types de classes d’analyse, à savoir les
dialogues, les contrôles et les entités. Nous respectons également les règles que nous
avions fixées sur les relations entre classes d’analyse, mais en nous intéressant cette
fois-ci aux interactions dynamiques entre objets :
◆ Les acteurs ne peuvent interagir (envoyer des messages) qu’avec les dialogues.

◆ Les dialogues peuvent interagir avec les contrôles.

◆ Les contrôles peuvent interagir avec les dialogues, les entités, ou d’autres contrôles.

◆ Les entités ne peuvent interagir qu’entre elles.

Pour chaque cas d’utilisation, nous réalisons un diagramme de séquence détaillé représentant
notre choix d’allocation de responsabilités dynamiques.

42
 4.1 Diagramme de séquences de « S’authentifier »

Un tiers (administrateur ou utilisateur) veut accéder à l’application.

Sur la page d’authentification, l’utilisateur saisit ses paramètres d’identification, la vérification

des paramètres est de la responsabilité de la classe de dialogue IIden.
Le contrôle CUsers délègue ensuite à une entité users la recherche proprement dite. L’entité
renvoie le(s) résultat(s) de la recherche au contrôle. Celui-ci initialise le dialogue IIdent, en lui
passant le(s) résultat(s).

Figure 11: Diagramme de séquences de « S’authentifier »

4.2 Diagramme de séquences de « Produire des données pour kafka »

Le développeur doit choisir les données d’entrée de notre méthode. Lors de

l’acceptation de donnée notre application prend en charge de structurer les données recevoir,
dans notre cas il faut structurer en format JSON, après elle envoie a Kafka. Kafka stocke ses
données dans un Topic en donnant un offset unique.

43
 Figure 12: Diagramme de séquences de « Produire des données pour kafka »

4.3 Diagramme de séquences de « Consommer des données de kafka »

Notre application demande d’abonné à Kafka pour consommer les données existant dans un
certain Topic. Après s'être abonné à un ensemble de sujets, le consommateur rejoindra
automatiquement le groupe lorsque le sondage (long) est appelé.

Le consommateur restera dans le groupe et continuera à recevoir des messages des partitions
qui lui ont été attribuées.

44
 Figure 13: Diagramme de séquences de « Consommer des données de kafka »

4.4 Diagramme de séquences de « Ajouter Paramètre de Mappage »

L’agent demande le formulaire d’ajouter d’un paramètre de mappage, l’application donne le

formulaire ajoutant la liste des opérations disponible dans le but de saisir le nom de champs
disponible et leur correspondante de champs de webservice demande.

L’agent remplir le formulaire lors de l’existant de ce champ dans la même opération le

système retourne une erreur d’enregistrement et demande à l’utilisateur de vérifier les donner
saisie.

45
 Figure 14: Diagramme de séquences de « Ajouter Paramètre de Mappage »

4.5Diagramme de séquences de « Edit Paramètre de Mappage

En cas ou l’agent saisie des données qui sont erronée, il demande un formulaire d’éditer ses donnée,
l’application récupéré ses donnée et donner un formulaire pour l’édition en remplissant les champs
avec l’ancien donnée.

46
 Figure 15: Diagramme de séquences de « Edit Paramètre de Mappage

5. Diagramme des classes

Dans cette partie nous allons définir les différentes classes qui vont répondre aux cas
d’utilisation. Le digramme de classes est une représentation graphique qui permet de représenter
les différentes relations entre les constituants de notre system. Une classe est un ensemble
d’attributs et des fonctions qui décrit le comportement d’un objet.

47
 Figure 16: Diagramme de classes

6. Conclusion

Dans ce chapitre nous avons définir l’architecture de notre application puis nous avons
détaillé la conception UML sous différents points statiques : diagramme de classes et
dynamique : diagramme de séquences, diagramme d’états des transitions et diagramme
d’activités.

Après la phase conception nous allons entamer la phase réalisation.

48
Chapitre IV : Réalisation

49
 1. Introduction
Après avoir décrit la conception de l’application, nous traiterons dans ce chapitre la
partie réalisation et mise en œuvre des fonctionnalités de notre application.

Nous présenterons en premier lieu l’environnement de travail, suivi d’un aperçu sur le
travail réalisé par le biais d’un ensemble de copies d’écran.

2. Langages et outils de développement :

2.1 Framework Spring

Spring est un Framework open source pour construire et définir l'infrastructure d'une
application Java3, dont il facilite le développement et les tests.

Figure 17: logo de spring framework

3.10 Bootstrap

C’est un ensemble des outils principalement utilisé pour la création des applications web. Il
contient des fichiers CSS, JavaScript, code HTML et des composants comme les boutons, les
navbars etc.…

3. Environnement matériel :

Le développement de notre application est fait sur un ordinateur portable qui possède les
caractéristiques suintantes :

• Marque : DELL
• Processeur : Intel Core i7-4710MQ @ 2.50 GHz 2.50 GHz

50
• Mémoire vive : 16 Go

4. Environnement logiciel
4.1 Eclipse

Eclipse est un projet, décliné et organisé en un ensemble

de sous-projets de développements logiciels, de
la fondation Eclipse visant à développer un
environnement de production de logiciels libre qui soit
extensible, universel et polyvalent, en s'appuyant
principalement sur Java.

4.2 Apache Kafka

Apache Kafka: est un projet à code source ouvert d'agent

de messages développé par l'Apache Software
Foundation et écrit en Scala. Le projet vise à fournir un
système unifié, en temps réel à latence faible pour la
manipulation de flux de données. Sa conception est
fortement influencée par les journaux de transactions.

4.3 StarUML

Dans la phase de conception, nous avons utilisé le langage

de modélisation UML avec l’outil open source StarUML
qui permet de créer les diagrammes essentiels pour avoir
un système bien structuré.

51
 4.4 Oracle Database
Dans le choix d’un SGBD on a choisi oracle car
c’est un moteur de base de données très solide
qui permet de gérer de grands volumes de
données.

5. Interfaces de système
5.1. Kafka

Création d’un Topic :

La figure14 représente la création d’un Producer avec la commande disponible par kafka,
après la création on va consulter tous les topics disponibles dans le cluster.

Command: [Link] --create --zookeeper localhost:2181 --replication-factor 1 --

partitions 1 --topic POSTE

Figure 18: Création de topic

Pour tester la bonne installation, configuration et fonctionnement de kafka, on va créer un

consumer et un Producer à l’aide de l’invite de commande avant commencer le
développement.

La figure 15 présente la création de Producer et le résultat obtenu :

52
 Figure 19: Création de Producer

La figure 16 présente la création de consumer et le résultat obtenu :

Figure 20: Création de consumer

5.2. API Producer

Ce module est un fichier JAR composé des classes java qu’utilise l’API disponible de Kafka
pour faciliter au développeur d’envoi la donnée nécessaire à Kafka Producer.

Ses classes contient des méthodes qui permettent de structurer et envois des données.

La figure 17 présente les configurations nécessaires pour assure la communication à Kafka

broker.

• [Link] : Définit les brokers (bootstrap servers) ;

• [Link] et [Link] : Définit comment sérialiser les paires clé / valeur.

Inclure des données dans un flux, mettre en série des données, après conversion dans
un format donné. Pour "désérialiser", il faut instancier la classe ObjectInputStream.
Cette opération consiste à ouvrir un flux en lecture, flux qui possède la capacité de
convertir la suite d'octets dans le type de l'objet auquel s'applique la méthode de
53
 lecture

• retries : Définit le nombre de renvoie des tous les enregistrements dont

l’envoie est échoué

Figure 21: « Producer » configuration

Les méthodes ci-dessous sont des méthodes prédéfinis, l’objectif de ses méthodes est
d’utiliser les API de Apache Kafka et envoyer les données à Kafka

Figure 22: Méthode d’envoyé les données à Kafka

Pour la traçabilité nous avons écrit une méthode permettant de créer un fichier log personnalisé
et enrichi celui obtenu de Kafka avec plus de détails.

54
La figure 23 présente la méthode développer pour la gestion des logs personnalisés de l’API
Producer.

Figure 23: Création de log personnalisé pour l'API Producer

L’étape suivante de développement de notre API est l’export en tant qu’un fichier jar intégrer
dans le système métier.

55
La figure 24 présente l’exportation d’un fichier JAR.

Figure 24: JAR exportation

5.3. API Consumer

Le principe de cette fonction est de tourner dans un mode continu, consommer les informations
de Kafka et faire des appels au Web service interne.

La figure 25 présente les configurations nécessaires à la bonne communication entre l’API

consumer et Kafka :

• [Link] : Dirige le consommateur vers les brokers.

• [Link] : Définit le groupe de consommateurs (tous les consommateurs doivent

appartenir à un groupe).

• [Link] et [Link]: Définissent comment sérialiser les paires clé /

valeur

56
 Figure 25: « Consumer » configuration

Après la configuration, nous avons utilisé les méthodes de l‘API Kafka consumer pour
s’abonner et consommer les données existantes dans Kafka Topic.

Pour chaque donnée consommée nous la structurons sous format JSON et utilisons une méthode
que nous avons développée pour appeler le web service de MPHANNIBAL.

Le principe de la méthode runConsumer (cf. figure 26) est de créer le « consumer », structurer
les données et appeler le web service.

57
 Figure 26: Principe de la méthode « runConsumer »

La figure 27 présente la méthode développée pour appeler le web service de MPHANNIBAL.

Figure 27: Appel du web service

58
Ensuite, nous avons créé une méthode « Log Consumer » pour la gestion de log personnalisé
de l’API Consumer (cf figure 28)

Figure 28: Log Consumer

5.4. MPHANNIBAL

Cette section sera réservée à la présentation de la majorité des scénarios possibles dans notre
site à travers des captures d’écrans des interfaces.

Nous commençons tout d’abord par l’interface d’authentification :

a. Interface « Authentification »
Dès que l’utilisateur entre des paramètres d’identification corrects (login et mot de passe), il
accède à la page d’accueil de notre application.

59
 Figure 29: Interface « Authentification »

b. Interface « Consulter liste des opération »

Cette interface (cf. figure 30) permet à l’utilisateur de consulter les différentes opérations
présentes dans notre système. Elle permet aussi d’ajouter, éditer ou supprimer dans le cas où
une erreur survient pendant l’enregistrement :

Figure 30: Interface « Consulter liste des opérations »

60
 c. Interface « ajouter une opération »
Cette interface (cf figure 31) permet à l’agent d’ajouter une opération. Cette opération existe
déjà dans le système « Métier » développé par MpSoft.

Figure 31: Interface « ajouter une opération »

d. Interface « éditer une opération »

Cette interface (cf. figure 32) permet à l’utilisateur de modifier les données d’une opération.

Figure 32: Interface éditer une opération

61
 e. Interface « Consulter liste des Mappage »
Cette interface (cf figure 33) permet l’affichage des listes des champs des différentes opérations
et leur correspondant dans les champs de web service, la modification et la suppression d’un
mappage spécifique

Notre système assure l’unicité de chaque champ.

Figure 33: Interface « Consulter liste des Mappage »

62
 f. Ajouter un mappage
Cette interface (cf figure 34) permet d’afficher le formulaire à remplir pour ajouter un nouveau
mappage.

Chaque opération de système contient son propre champ et son correspondant au champ de web
service. Nous offrons donc une liste qui contient les opérations pour choisir le champ
correspondant à l’opération choisie.

Figure 34: Interface « ajouter un mappage »

63
 g. Interface « Consulter liste des Web Service »
La figure 35 présente l’interface « Consulter liste des Web Service » permettant d’afficher
chaque opération et son nom et le lien au web service qui lui correspond. Chaque opération peut
avoir un ou plusieurs web service mais un web service ne peut avoir qu’une seule opération.

Figure 35: Interface « Consulter liste des Web Service »

64
 h. Ajouter un web service
La figure 36 présente l’interface « Ajouter un web service ».

Chaque web service se caractérise par un nom, une adresse et l’opération qui invoque ce web
service.

Figure 36: Interface ajouter un web service

65
 i. Web service de MPHANNIBAL
La figure 37 présente le web service de MPHANNIBAl. Ce web service générique accepte tout
JSON et permet aussi le mappage des champs et l’invocation des web services d’une manière
automatique.

Figure 37: Web service MPHANNIBAL

66
 j. Mapping
La figure 38 présente la méthode de mappage des champs web service. Cette méthode accepte
le JSON arrivant du web service comme attribut puis le transforme en Map pour le mappage.

Le mappage se fait à l’aide d’une méthode transform que nous avons développée.

Figure 38: Méthode de mappage

67
Pour tester le web service « Mapping » nous avons utilisé l’outil Postman.

Figure 39: Test de web service

68
 k. Invocation de web service de Hannibal
La figure 40 présente la méthode utilisée pour invoquer les web service de Hannibal.

Nous avons ajouté une méthode de gestion de log personnalisé pour sauvegarder les requêtes
HTTP et leur réponse.

Figure 40: méthode d'invocation de web service

6. Conclusion
Dans le chapitre réalisation nous avons défini les différents langages et outils de
développement. Puis, nous avons présenté les composant de notre système en finissant par la
présentation des interfaces de notre application.

69
 Conclusion Générale

Ce rapport résume les résultats de mon projet de fin d’étude pendant les quatre mois qui sont
dédiés pour la réalisation de notre application web « Système de déclaration règlementaire
Asynchrone ».

Ce projet m’a offert l’occasion d’apprendre et de suivre une formation pour de nouveaux
langages de programmation comme le langage de programmation orienté objet JAVA, HTML
comme langage de balisage, CSS pour la gestion d’une meilleure présentation et javascript. En
effet, ce projet était pour moi une occasion pour assimiler les nouveaux outils, mis à notre
disposition pour le développement de notre application, tel que le Framework Spring, Bootsrap,
Jquery.

Lors de la phase de réalisation nous avons rencontré quelques problèmes, comme tout projet,
en ce qui concerne l’installation et l’intégration d’Apache Kafka sur l’environnement de
développement dû à un manque de l’information puisque Kafka est un nouvel outil. Aussi nous
avons rencontré un problème lors de l’utilisation et l’adaptation des méthodes déjà existantes dans
les API de Kafka.

Notre application peut être améliorée ultérieurement en ajoutant d’autres fonctionnalités qui
la rendraient plus performante et efficace.

Au-delà de l’aspect technique, nous avons eu la chance de développer notre esprit d’analyse
et d’assurer une formidable expérience avec les employés de la société MpSoft, qui nous ont fait
bénéficier de leur expérience et de leur professionnalisme.

Finalement, ce projet a été une bonne opportunité pour l’intégration dans une société
spécialisé dans le développement web qui m’a permis d’évaluer ma compétence dans ce domaine.

70
 Acronymes
A

API : Application Programming Interface

BCT : Banque Centrale de Tunisie

CSS: Cascading Style Sheets

CTAF : COMMISSION TUNISIENNE DES ANALYSES FINANCIÈRES

DAO: Data Access Object

DOM: Document Object Model

HTML: Hypertext Markup Language

HTTP: HyperText Transfer Protocol

Icsp : Instrument contribuant à la stabilté et à la paix

MSQL: Mini SQL

MVC: Model View Controller

ORM: Object-relational mapping

Rest: Representational state transfer

71
 Bibliographie

[Link]
[Link]
[Link]
[Link]
[Link]
[Link]

72
Résumé :

Ce rapport présente le travail que nous avons réalisé durant notre stage de fin
d’études consiste à implémenter un Système de déclaration règlementaire
Asynchrone au sein de la société MpSoft. Nous avons commencé par une
analyse des besoins suivie d'une conception architecturale détaillée de la
solution envisagée. Pour l'implémentation, nous avons utilisé Eclipse comme
outil de réalisation qui nous a permis d'obtenir à la fin des interfaces
ergonomiques et faciles à utiliser. Mots clés : Cycle en v, Asynchrone, Web
service, Kafka.

Summary :

This report presents the work that we carried out during our end of studies
internship consists of implementing an Asynchronous regulatory reporting
system within the company MpSoft. We started with a needs analysis followed
by a detailed architectural design of the proposed solution. For the
implementation, we used Eclipse as an implementation tool which allowed us to
obtain ergonomic and easy to use interfaces at the end of the day. Keywords:
Cycle in v, Asynchronous, Web service, Kafka.

‫ ملخص‬:

‫يعرض هذا التقرير العمل الذي قمنا به خالل نهاية تدريبنا للدراسات والذي يتكون من تطبيق نظام إعداد‬
‫ التقارير التنظيمية غير المتزامن داخل شركة‬MpSoft. ‫عا بتصميم‬
ً ‫بدأنا بتحليل االحتياجات متبو‬
‫ استخدمنا‬، ‫من أجل التنفيذ‬. ‫ معماري مفصل للحل المقترح‬Eclipse ‫كأداة تنفيذية سمحت لنا بالحصول‬
‫الكلمات المفتاحية‬. ‫على واجهات مريحة وسهلة االستخدام في نهاية اليوم‬: Cycle in v،
Asynchronous، Web service، Kafka