Simulation d’une cryptomonnaie basée sur la devise monétaire congolaise.

CHAPITRE TROISIEME

MODELISATION DU SYSTEME

Introduction

Tout en présentant l'idée générale de notre système, ce présent chapitre est subdivisé en deux parties ; la première consiste à faire une présentation du système tout en présentant les objectifs et services que le système sera à mesure de réaliser.

En deuxième lieu, nous présentons notre façon de procéder (méthode) pour présenter l'analyse et la spécification des besoins, suivie de la conception du système. L'étape d'analyse et de spécification des besoins offre une description de l'application suivie des besoins fonctionnels et non fonctionnels.

EXIGENCES FONCTIONNELLES DU SYSTEME

L'objectif du système.

L'objectif de notre travail est de simuler un système pair-à-pair de payement sur internet basé sur la devise monétaire congolaise tout en respectant les modes de sécurité des cryptomonnaies sur internet. L'unité de compte utilisé par ce présent système nous l'avons dénommé « talentcoin »

Contrairement au protocole Bitcoin, qui, sa découverte des noeuds s'effectue en interrogeant un DNS tout en utilisant un certain nombre de graines DNS (DNS seeds), des serveurs DNS qui fournissent une liste d'adresses IP de noeuds bitcoin. Nous avons pensé utiliser la DHT pour la découverte de nouveaux noeuds. La connaissance géographique des noeuds n'est pas nécessaire.

Le système implémente certaines fonctionnalités que nous décrivons ici-bas :

34

Créer Wallet.

Une foi l'application lancée pour la première fois, elle demande quelques informations pour la sécurité complémentaire du wallet; l'application génère automatiquement une paire des clés pour la sécurité lors de l'échange des informations sur le réseau.

Authentification.

L'authentification est l'une des fonctionnalités très nécessaires dans ce système, car une fois ses clés volées ; c'est tous les coins du wallet qui sont bien volés. Il existe deux types d'authentifications :

? Au niveau de l'application : permet d'accéder à l'interface de l'application

? Au niveau du réseau : effectué automatiquement par le système, toute action au niveau

du réseau est vérifié par l'ensemble du système.

Recevoir des talentcoins.

Cette fonctionnalité permet à l'utilisateur de se procurer le talentcoin, il peut s'effectuer à partir du site web du système ou à partir d'un autre utilisateur d'une manière traditionnelle en lui donnant une valeur physique et son adresse d'indentification sur le réseau.

Envoyer des talentcoins.

On peut vendre les coins que nous possédons dans notre wallet, sur ce, il faut avoir l'adresse du destinateur.

Miner des talentcoins.

Le minage est la fonctionnalité qui permet de sécuriser le réseau. Cette fonctionnalité est rémunérée par une petite somme de coin pour sa preuve de fonctionnalité.

35

Besoins Fonctionnels du système.

Les différentes fonctionnalités qu'offre le système, y sont toutes accédées après une authentification sauf pour celle de la création de wallet. Cette fonctionnalité permet d'assurer l'authenticité de l'acteur. Nous possédons trois acteurs pour le système ; « Le client » ; celui-ci est toute personne voulant participer au fonctionnement du système ; « L'utilisateur » est celui qui participe déjà ; enfin nous avons « le système de payement sécurisé ».

? Fonctionnalité de créer wallet : Permet de créer un portefeuille afin de participer sur le
réseau talentcoin.

? Fonctionnalité Authentification : cette fonctionnalité permet à l'utilisateur d'assurer sa
sécurité au niveau logiciel

? Fonctionnalité Achat talentcoin : Permet de se procurer des talentcoins sur le réseau

? Fonctionnalité Vente talentcoin : Permet de vendre ses coins que l'on possède dans

son portefeuille à un autre utilisateur dans le réseau.

? Fonctionnalité minage : Cette fonctionnalité est celle qui permet de sécuriser
l'ensemble du réseau, en validant les transactions effectuées sur le réseau.

Besoins non-fonctionnels du système.

Les besoins non fonctionnels décrivent toutes les contraintes auxquelles est soumis le système pour sa réalisation et son bon fonctionnement.

? Existence d'un réseau ;

? Ergonomie attractive et efficace : le design des interfaces doit permettre une

identification immédiate pour permettre à l'utilisateur d'accéder facilement aux différentes fonctionnalités du système ;

? Rapidité du traitement : le système doit assurer une rapidité de traitement pour qu'elle
s'approche au maximum d'une exécution en temps réel.

Figure 12: Diagramme de cas d'utilisation

36

Diagramme de cas d'utilisation.

Règles de gestion fonctionnelle.

Notre modèle est alimenté par les règles suivantes :

1. Toute fonctionnalité ne pourra être utilisée que s'il y a une authentification de la part
de l'utilisateur, sauf la fonctionnalité de créer wallet.

2. Une fois une authentification validée, l'utilisateur peut :

- Recevoir des talentcoins

- Envoyer des talentcoin

- Miner des talentcoin

37

Description textuelle des cas d'utilisation. Le cas « créer wallet»

Tableau 2. cas créer wallet

Description

Titre Créer wallet

Résumé Permet au client de se procurer un portefeuille pour effectuer les

opérations que réserve le système.

Acteurs Le client

Précondition L'acteur doit se procurer l'application mobile ou desktop selon sa

plateforme

Scenario Nominal 1. Lancement du setup de l'application

2. L'application demande à l'acteur quelques informations

3. L'utilisateur fournit les informations nécessaires pour la sécurité de l'application

4. L'application effectue la configuration de l'identité de l'acteur

5. Une fois configuration finie, le wallet est créé

6. Fin

Scenario Alternatif 1. si le client fournit les informations invalides, le scénario

reprend de 2

Le cas « Authentification »

Tableau 3. Le cas Authentification

Description

Titre Authentification

Résumé En entrant un login et mot de passe, ce cas Permet une authentification

38

de l'utilisateur pour accéder aux menu du système

Acteurs L'utilisateur

Précondition L'utilisateur doit avoir un compte sur l'application

Scenario Nominal 1. L'utilisateur lance l'application

2. L'application suggère à l'acteur le menu d'authentification

3. L'utilisateur fourni ses identifiants à l'application

4. L'application vérifie si l'utilisateur valide

5. Ouverture de l'interface d'accueil

6. Fin

Scenario Alternatif 1. si le client fournit les informations invalides, le scénario

reprend de 2

Le cas Recevoir talentcoins

Tableau 4: Le cas Recevoir talentcoins

Description

Titre Recevoir talentcoins

Résumé Permet à l'utilisateur de demander de lui envoyer des nouveaux

talentcoins.

Acteurs L'utilisateur

Précondition L'utilisateur doit se connecter

Scenario Nominal 1. L'utilisateur lance l'application

2. L'utilisateur effectue l'authentification

3. L'utilisateur accède à l'interface d'accueil où il choisit le menu recevoir.

4. L'utilisateur fournit l'adresse de destination

5. Il donne le nombre de talentcoins qu'il veut s'en procurer puis envoie les informations.

6. Fin

39

Scenario Alternatif 1. si authentification invalide, le scénario reprend de 2

2. si le système ne reconnaît pas l'adresse de destination, le

scénario reprend de 4 ;

Le cas Envoyer talentcoins

Tableau 5: Le cas Envoyer talentcoins

Description

Titre Envoyer talentcoins

Résumé Permet à l'utilisateur d'effectuer une transaction vers un autre compte

d'utilisateur

Acteurs L'utilisateur

Précondition L'utilisateur doit avoir un nombre de talentcoins nécessaire pour la

transaction

Scenario Nominal 1. L'utilisateur lance l'application

2. L'utilisateur effectue l'authentification

3. L'utilisateur accède à l'espace Envoyer des talentcoins

4. Il fournit l'adresse vers lequel il veut effectuer la transaction et le nombre de talentcoins qu'il veut envoyer puis envoie.

5. La transaction est ajoutée dans un block

6. Le réseau valide la transaction

7. Le destinateur reçoit la transaction

8. Fin

40

Scenario Alternatif 1. si l'authentification invalide, le scénario reprend de 2

2. si l'adresse d'envoi est invalide, le scénario reprend de 4 ;

3. si le réseau invalide la transaction, le scénario reprend de 4

Le cas miner talentcoins

Tableau 6: le cas miner talentcoins

Description

Titre Miner talentcoins

Résumé Comme la chambre de compassassions pour les banques

traditionnelles, ce cas permet de valider les transactions et de créer des nouveaux talentcoins. Il permet de sécuriser le réseau talentcoins.

Acteurs L'utilisateur

Précondition La machine ayant configuré cette fonctionnalité doit rester allumée

tout le temps pour effectuer le minage.

Scenario Nominal 1. La machine effectue l'opération mathématique de validation

de nouvelles transactions regroupées dans un block

2. Le block validé est ajouté à la blockchain et transmises à l'ensemble du réseau

3. Le réseau récompense l'utilisateur de nouvelles monnaies

4. Fin

Scenario Alternatif 1. si les transactions validées les sont déjà par une autre machine,

le scénario reprend de 1

41

CONCEPTION DU SYSTEME

Diagramme de séquences.

Créer wallet.

Nous commençons par la création du wallet de l'acteur qui veut participer au système (client). Le système possède deux types de wallet, l'un qui peut être créé sur une plateforme web et l'autre sur une plateforme desktop ou mobile. Ici nous présentons comment se présente le scénario sur toute les plateformes.

Figure 13: diagramme de séquence "créer Wallet"

Authentification.

Cette section montre le scénario pour l'authentification dans le but d'accéder à son espace utilisateur afin d'avoir la facilité de bénéficier aux fonctionnalités du système. Une authentification réussit est une inclusion du client ayant déjà créé un wallet (Desktop, mobile, web) (utilisateur).

42

Figure 14: diagramme de séquence " authentification "

Recevoir talentcoins.

Dans la figure présentée ici-bas, nous présentons le scénario pour l'opération recevoir des talentcoins. L'authentification est une précondition de cette séquence.

Figure 15: diagramme de séquence " Recevoir talentcoins "

Vendre talentcoins.

Cette séquence est autrement dite la transaction, elle présente l'ensemble des séquences qui interviennent dans la fonctionnalité de vente des talentcoins. La figure ici-bas nous décrit cette opération d'une manière séquentielle.

43

Figure 16: diagramme de séquence " Envoyer talentcoins "

Miner talentcoins.

Cette section permet de montrer comment s'effectue la validation d'une transaction d'un pair à un autre dans le réseau Talentcoin tout en les ajoutant dans un bloc. Cette fonctionnalité est celle qui permet de créer des novelles monnaies et trouver le prochain block. Ces monnaies créées sont une récompense de la validation. Présentée dans la figure ci-dessous.

44

Figure 17: diagramme de séquence " Miner talentcoins "

Diagramme de déploiement.

Un utilisateur est enregistré au moins dans une DHT pour participer aux fonctionnalités du réseau Talentcoin.

45

Figure 18: Diagramme de déploiement du réseau Talentcoin

? DHT : celle-ci possède la liste d'adresse IP des pairs connectés au réseau « dht.xml»

? Utilisateurs : Ceux-ci possèdent tous :

- Toutes les transactions valides regroupées par bocks puis celui-ci est ajouté à la chaine

de blocks« blockchains.xml»

- Les notifications des transactions auxquelles il est lié ainsi que du
système « notifications.xml».

- La configuration de l'application « configurations.xml»

Diagramme de classe.

Règles de gestion fonctionnelle.

Les Règles de gestion fonctionnelle sont des normes qui s'appliquent systématiquement dans le système lorsque l'acteur effectue une opération quelconque (DIGALLO, 2001).

1. Un utilisateur possède un nom d'utilisateur, un mail et un mot de passe qui lui
permettent de s'identifier au niveau applicatif et enfin il possède une adresse lui permettant de recevoir des nouvelles monnaies. ; une adresse IP qui lui attribuée pour chaque connexion ;

2.

46

Un utilisateur peut ou ne pas effectuer des transactions ; celle-ci possède une date de transaction, une adresse du destinateur, la somme et la signature de l'émetteur de la transaction ;

3. Il existe deux type de transactions ; les entrées et les sorties.

4. Une transaction réalisée est automatiquement ajoutée dans un bloc.

5. Un block possède un index permettant de savoir le numéro du bloc, un nonce qui sert lors du minage du bloc, un timeStamp qui stock la date de création du bloc, un hash pour assurer l'intégrité du bloc, un previousHash pour lier le block courant au précédent et une signature pour signaler l'utilisateur ayant trouvé le bloc et ne coinbase.

6. En fin, un utilisateur peut ou ne pas avoir une notification, qui possède la date, la description, un identifiant et un type.

Diagramme de classe de conception.

Figure 19: Diagramme de classe

47

Base des données.

Afin de constituer notre base de données, nous sommes parti de quelques six principes

de transformation (Transformation des classes, Transformation de l'héritage, Association un-

à-plusieurs, Associations plusieurs-à-plusieurs ou classes-associations, Associations un-à-un,

Composition) (Masivi, 2018).

Ces règles nous ont permis d'avoir ce qui suit :

Utilisateurs (userName, password, adressIp, adressTalentcoin) ;

Transactions (adresseDestinataire, dateTransaction, signature, somme) ;

Blocks (index, hash, coinbase, previousHash, nonce, timeStamp, Transaction);

Notifications (id, date, type, description) ;

recevoirNotification(idNotification#, idUtilisateurs#) ;