MoBlo, Modélisation pour BlockChain

La BlockChain est une technologie de transactions partagées, ou non, par des utilisateurs. Comme toute technologie, la BlockChain a besoin d’outils de modélisation pour guider la conception de projets et chaque partie du projet a besoin de pouvoir modéliser avec le même outil de manière à être compris par toutes les personnes travaillant sur le projet (les personnes techniques, les chefs de projets, les maîtrises d’ouvrage, …). Tout comme une illustration permet de s’accorder sur une interface, tout comme l’UML permet de s’accorder sur le fonctionnement d’un logiciel, il est nécessaire de s’accorder sur les rôles des utilisateurs de la BlockChain ainsi que sur les différents types d’interactions.

MoBlo est une Modélisation pour BlockChain. Ce document présente :

Le Contexte des cas qui serviront d’exemple tout au long du document;
Le diagramme Population Map, “Carte de la population” qui permet de définir le spectre des utilisateurs de la BlockChain ainsi que leurs droits;
Le diagramme Global Architecture, “Architecture Globale” qui permet de définir la place de la BlockChain au sein du système et la façon d’interagir avec elle;
Le diagramme Unit Definition, “Définition des unités” qui permet de définir les objets qui seront manipulés par la BlockChain;
Le diagramme Business Transactions, “Transactions Métier” qui permet de définir les différentes transactions nécessaires au projet;
La Conclusion.

1. Contexte

Dans ce document, MoBlo sera présentée sur deux exemples différents. Les deux sections suivantes présentent ces deux exemples.

1.1. Exemple 1 : Bibliothèque

Une grande ville gère plusieurs bibliothèques, à titre d’exemple et pour le simplifier, prenons une au Nord, une au Sud, une à l’Ouest, une à l’Est et une bibliothèque Centrale.

La bibliothèque Centrale est responsable de l’achat de nouveaux livres. Les livres sont distribués aux différentes bibliothèques. La quantité de livres achetés dépend de l’intérêt accordé aux livres. Certains livres sont achetés en un seul exemplaire et doivent être partagés par les bibliothèques. D’autres livres sont achetés en plusieurs exemplaires et peuvent être trouvés dans chaque bibliothèque.

Les lecteurs doivent avoir un droit d’accès pour emprunter des livres. Ils peuvent emprunter des livres dans n’importe quelle bibliothèque, mais ils sont limités à 10 livres. Ils peuvent rendre les livres empruntés dans n’importe quelle bibliothèque même dans une autre bibliothèque que celle où ils ont empruntés les livres. Les lecteurs peuvent commander des livres dans une bibliothèque spécifique. Lorsque le livre commandé sera disponible, le livre sera conduit dans la bibliothèque choisie par le lecteur. Un lecteur peut commander jusqu’à 2 livres en même temps.

1.2. Exemple 2 : Forum

Quelqu’un veut créer un forum à accès limité sans utiliser les outils Web habituels. Les utilisateurs peuvent créer de nouveaux articles. Les utilisateurs peuvent commenter une autre publication ou un autre commentaire. L’auteur de l’article est responsable de la communication autour de son article. Il décide qui est capable de commenter son article.

2. Population Map (PM), la “Carte de la Population”

La première étape dans la mise en place d’un projet BlockChain est la définition du périmètre : quels sont les droits de chaque acteur (final) du projet.

2.1. Les Droits

Cette section présente quels différents types de droits peuvent être donnés aux différents acteurs d’un projet BlockChain.

Ces différents droits sont définis ci-dessous pour les différentes adresses de la BlockChain. Une adresse correspond à un identifiant personnel sur la BlockChain (comme pourrait l’être une adresse mail sur serveur de mail). Un noeud est un moyen de se connecter au réseau (ordinateur, smartphone, …).

Elément de diagramme	Description
	Connect, “Connection” : Adresse ayant le droit de se connecter à la BlockChain.
	Send, “Envoi” : Adresse ayant la possibilité d’envoyer de nouvelles transactions dans la BlockChain (possède implicitement le droit de se connecter)
	Receive, “Reception” : Adresse ayant la possibilité de recevoir des transactions dans la BlockChain (possède implicitement le droit de se connecter)
	Issue : Adresse ayant le droit de créer de nouveaux Assets dans la BlockChain (possède implicitement le droit d’envoi et de réception, la notion d’Asset sera abordée avec le diagramme de Définition des Unités)
	Miner, “Mineur” : Noeud qui gère la création de blocks dans la BlockChain.
	Simple Node, “Noeud Simple” : Noeud qui n’est pas capable de se connecter à la BlockChain (donc noeud hors réseau).
	Activator, “Activateur” : Peut donner et retirer, à n’importe quelle adresse, les droits : connect, send, receive.
	Admin : Peut donner et retirer différents droits à n’importe quelle adresse : issue, mine, activate, admin, connect, send et receive.
	Origin Node, “Noeud d’Origine” : Créateur de la BlockChain (_possède naturellement les droits d’administration).

2.2. Le diagramme PM pour le use case Bibliothèque

Dans le cas de la Bibliothèque, on peut trouver 4 types d’acteurs :

Central Library : La Bibliothèque Centrale
Libraries : Les Bibliothèques Secondaires
Readers : Les Lecteurs
Others : Les Autres Acteurs (non reliés au système de Bibliothèques)

L’ensemble des droits peut être représenté par la figure suivante :

{% responsive_image path: assets/images/post/moblo-fr/PM-Library-Ext.png alt:“PM-Library-Ext” class=“align-center”%}

Figure 2-1 - Population Map - Bibliothèque - étendu

Repassons en revue les droits de chaque acteur :

La Bibliothèque Centrale :
- C’est le Créateur de la BlockChain
- Il a les droits Admin sur la BlockChain
- Il a les droits Activateur sur la BlockChain
- C’est un Mineur
- Il peut se Connecter à la BlockChain
- Il peut Envoyer des transactions sur la BlockChain
- Il peut Recevoir des transactions sur la BlockChain
- Il a le droit d’Issue, c’est à dire de créer de nouveaux Assets dans la BlockChain
Les autres Bibliothèques :
- Ils ont le droit Activateur sur la BlockChain
- Ils sont Mineurs
- Ils peuvent se Connecter à la BlockChain
- Ils peuvent Envoyer des transactions sur la BlockChain
- Ils peuvent Recevoir des transactions sur la BlockChain
Les Lecteurs :
- Ils peuvent se Connecter à la BlockChain
- Ils peuvent Envoyer des transactions sur la BlockChain
- Ils peuvent Recevoir des transactions sur la BlockChain
Les autres Acteurs (non rattachés au système de la Bibliothèque) :
- Ils ne peuvent pas se connecter !!! Ils ne peuvent donc pas lire les informations.

Dans cette liste, plusieurs droits sont redondants.

Si on est en mesure d’écrire dans la BlockChain, alors on a, inévitablement, le droit de se connecter à la BlockChain. De façon similaire, un créateur de BlockChain a les droits Admin et Activation.

Note: c’est un bon moyen de mettre en avant les rôles, les acteurs techniques, les acteurs métier.

La liste peut donc être réduite de la façon suivante :

La Bibliothèque Centrale :
- C’est le Créateur de la BlockChain;
- C’est un Mineur;
- Il peut Envoyer des transactions sur la BlockChain;
- Il peut Recevoir des transactions sur la BlockChain;
- Il a le droit d’Issue, c’est à dire de créer de nouveaux Assets dans la BlockChain.
Les autres Bibliothèques :
- Ils ont le droit Activateur sur la BlockChain;
- Ils sont Mineurs;
- Ils peuvent Envoyer des transactions sur la BlockChain;
- Ils peuvent Recevoir des transactions sur la BlockChain.
Les Lecteurs :
- Ils peuvent Envoyer des transactions sur la BlockChain;
- Ils peuvent Recevoir des transactions sur la BlockChain.
Les autres _Acteurs _ (non rattaché au système de la Bibliothèque):
- Ils ne peuvent se connecter !!! Ils ne peuvent donc pas lire les informations.

Les droits peuvent donc être représentés de manière compacte comme dans la figure suivante :

{% responsive_image path: assets/images/post/moblo-fr/PM-Library-Compact.png alt:“PM-Library-Compact” class=“align-center”%}

Figure 2-2 - Population Map - Bibliothèque - Compacte

2.3. Diagramme PM pour le use case Forum

Dans la cas du Forum, il y a 4 types de personnes :

Le Créateur du Forum
Les Editeurs (qui ont le droit de créer de nouveaux sujets)
Les Lecteurs Abonnés
Les (Simples) Lecteurs

L’ensemble des droits peut être représenté par la figure suivante :

{% responsive_image path: assets/images/post/moblo-fr/PM-Forum.png alt:“PM-Forum” class=“align-center”%}

Figure 2-3 - PM - Forum

La figure représente la version compacte de la Population Map (PM).

La liste des droits est la suivante :

Le Créateur du forum :
- C’est le Créateur de la BlockChain;
- Il est Mineur;
- Il peut Envoyer des transactions dans la BlockChain;
- Il peut Recevoir des transactions dans la BlockChain;
- Il a le droit d’Issue dans la BlockChain;
- Il peut Recevoir en utilisant une autre adresse.

Note : Le Forum possède un mur, une “ligne éditoriale”. Une adresse spécifique est créée à ce titre, pour recevoir toutes les publications. On peut imaginer que chaque éditeur possède sa propre adresse de publication et que le forum possède ainsi plusieurs lignes éditoriales. En fait, techniquement, si une adresse peut recevoir des transactions alors elle peut servir de ligne éditoriale. Il faut noter, avant tout, que le Créateur du Forum est représenté par deux statuts : le premier possède tous les droits (ce sont ses droits utilisateurs); le second ne peut que recevoir des transactions (c’est la ligne éditoriale).

Note : Une adresse qui ne peut que recevoir peut être considérée comme un mur de publication (une discussion ultérieure compare l’utilisation des transactions à l’utilisation des streams).

Les Editeurs (qui ont le droit de créer de nouveau sujets) :
- Ils peuvent Envoyer des transactions dans la BlockChain;
- Ils peuvent Recevoir des transactions dans le BlockChain;
- Ils ont le droit d’Issue dans la BlockChain.
Les Lecteurs Abonnés :
- Ils peuvent Envoyer des transactions dans la BlockChain;
- Ils peuvent Recevoir des transactions dans le BlockChain.
Les (simples) Lecteurs :
- Ils peuvent se connecter et lire (seulement lire) les publications.

2.4. Cas particuliers

Les exemples utilisées pour cette modélisation sont volontairement simples. Ils ne reflètent pas la réalité où peuvent se présenter des cas particuliers comme l’utilisation de multi-signatures, qui n’est pas si particulier, ou l’import d’une clé privée.

2.4.1 Cas particulier : Multi-Signature

Dans plusieurs cas, il peut apparaître le besoin d’utiliser une adresse multisignée. Une adresse multisignée est une adresse qui peut être signée par (p) clés publiques différentes et qui doit être signée par (s) signatures. Ainsi, une adresse multisignée est notée avec (s x p) pour informer du nombre (s) de signatures nécessaires parmi les (p) clés publiques possibles.

Dans le diagramme Population Map, un cadre supplémentaire est adjoint aux personnes pouvant signer et une information indique le format de la signature.

Figure 2-4- PM – Adresse MultiSignée

Dans cette figure, deux adresses sont partagées par Alice et Bob :

• la première adresse n’a besoin que d’une signature pour envoyer des transactions (soit la signature d’Alice, soit celle de Bob);

• La seconde adresse a besoin de deux signatures pour envoyer des transactions (la signature d’Alice et celle de Bob)

Note : Plusieurs diagrammes peuvent être utilisés quand plusieurs adresses multisignées se croisent, par exemple : quand une adresse est en 3 x 6 et une autre adresse en 4 x 5, et une autre … Le principe du diagramme Polupation Map est de clarifier la situation des différents acteurs, plusieurs diagrammes peuvent donc être utilisés pour conserver la clarté dans la représentation de la population.

2.4.2 Cas particulier : Import de Clé Privée

D’une manière générale, un utilisateur de BlockChain doit gérer plusieurs adresses, celle-ci sont conservées dans un portefeuille ou “wallet”. Dans certains cas, il peut s’avérer nécessaire d’importer la clé privée d’une adresse depuis un wallet vers un autre wallet. L’adresse peut, ainsi, être utilisée de la même façon depuis les deux wallets. C’est donc une fonctionnalité à utiliser avec beaucoup de prudence.

Dans le diagramme PM, cela se représente par une simple flèche.

Figure 2-5- PM - Import de Clé Privée

Dans cette figure, Bob a le droit d’Issue dans la BlockChain alors qu’Alice n’en a pas directement le droit, mais Alice a le contrôle sur une adresse du Wallet de Bob, Alice a, ainsi, le droit d’Issue en utilisant les droits de l’adresse de Bob.

Techniquement, cela signifie qu’Alice a importé la clé privée de l’adresse de Bob.

3. Global Architecture (GA), “l’Architecture Globale”

Lorsque les différents acteurs sont définis, il est nécessaire de définir l’Architecture Globale. Cette architecture permet de définir comment chaque “application” interagit avec la BlockChain. Cela permet, ainsi, de présenter, de façon explicite, les services externes à mettre en place.

3.1. Eléments d’architecture

Le tableau ci-dessous présente les différents éléments qui permettent de définir l’architecture globale d’un projet.

Elément de diagramme	Description
	BlockChain : Représentation de la BlockChain qui regroupe l’ensemble des noeuds d’une même BlockChain.
	Service Externe : Représentation d’un service externe qui a besoin d’accéder aux informations contenues dans le BlockChain.
	Application : Application utilisée par un utilisateur de la BlockChain.
	Lien : Lien entre le noeud (wallet) et l’utilisateur.

3.2. Le diagramme GA pour le use case Bibliothèque

Dans le cas de la Bibliothèque, chaque Bibliothèque a un intérêt à être directement connectée à la BlockChain.

Les Lecteurs n’ont, par contre, aucune raison de devoir installer ou configurer quoique ce soit sur leur système. Il est donc nécessaire de mettre en place un portail qui leur permettra d’accéder au service. Une autre raison de mettre en place le portail réside dans le manque d’intérêt pour les Lecteurs à posséder toutes les données de la BlockChain.

Note : la mise en place d’un wallet “léger”, c’est-à-dire ne possédant que les transactions propres au wallet, peut être présenté comme un service externe. Toutes les BlockChains ne le proposent pas.

Les Autres présentés dans le diagramme Population Map n’ont pas le droit de se connecter à la BlockChain, le portail mis en place doit donc posséder un accès limité.

En plus des acteurs présentés dans le diagramme PM, la mise en place de batches-scripts peut être nécessaire, par exemple pour créer et envoyer des notifications de retard par mail aux Lecteurs par exemple ou pour gérer les listes de livres devant être envoyés d’une Bibliothèque à l’autre.

Figure 3-1 – GA - Bibliothèque

La figure présente les 3 noeuds ayant des droits d’action sur la BlockChain. La Bibliothèque Centrale (CL) et les Bibliothèques secondaires (L) sont directement connectées à la BlockChain. Les Lecteurs utilisent un portail pour communiquer avec la BlockChain. Les batches utilisent l’adresse de la Bibliothèque Centrale pour accéder à la BlockChain.

3.3. Diagramme GA pour le use case Forum

Le but du Forum est de se séparer de tout outil web habituel (gardons en tête que la BlockChain reste synchronisée par le réseau). Mis à part l’envoi et la réception de transactions, il n’y a aucun cas particulier à identifier. Le Forum possède un mur de publication qui a pour finalité de rester ouvert à la lecture à tous.

Figure 3-2 - GA - Forum

3.4. Cas particuliers : Batches & SmartContract

Un Batch est considéré comme un service extérieur. Il est positionné à l’extérieur de la BlockChain et il utilise une adresse présente sur un wallet de la BlockChain. Le wallet appartient à un acteur de la BlockChain qui peut être clairement identifié, même dans le cas d’une adresse multisignée.

Figure 3-3 - GA - Batch

Un SmartContract est un “script” positionné au milieu de la BlockChain. Publier un SmartContract dans la BlockChain renvoie l’adresse du SmartContract dans la BlockChain. Un SmartContract peut donc être représenté comme une simple adresse avec un libellé pour indiquer qu’il s’agit d’un SmartContract.

Figure 3-4 - GA - SmartContract

Note : le diagramme GA a pour finalité de donner une représentation de l’architecture. Le contenu, au sens algorithmique, du Batch ou du SmartContract n’a pas à être défini par ce diagramme.

3.4. Cas particulier : Multi-Signature

Dans le cas particulier des adresses multisignées, le diagramme GA permet de définir ou redéfinir explicitement les clés publiques concernées.

Figure 3-5 - GA - MultiSig

La figure illustre le fait qu’Alice utilise une de ses adresses pour signer les transactions d’une adresse multisignée (M1) et une autre adresse pour signer les transactions effectuées avec l’autre adresse multisignée (M2).

Les libellés, ajoutés au niveau des adresses mutlisignées, permettent de les distinguer ultérieurement.

3.6. Cas Particulier : Les Canaux (Channels)

Plusieurs BlockChains définissent des canaux comme des parties fermées d’une BlockChain. On peut donner des droits particuliers à un Canal et donner d’autres droits à un autre. Jamais un Canal n’est inclus dans un autre Canal. Dans le diagramme GA, cela peut être représenté comme différentes BlockChain, chaque BlockChain ayant ses propres droits.

4. Unit Definition (UD), la “Définition des Unités”

Les transactions financières utilisent la crypto-monnaie (monnaie électronique) dans les transactions BlockChain. Les crypto-monnaies sont principalement utilisées dans des projets présentant un aspect financier.

Les transactions sans crypto-monnaie sont des transactions non-financières, on en distingue deux types :

Les transactions définies sont des transactions de blockChain utilisant des unités d’asset ou leur équivalent (colored coins, …) afin de définir un contenu associé à la transaction. Les unités d’assets sont donc des éléments typés qui peuvent être envoyés d’une adresse à une autre, tout comme on peut envoyer de la crypto-monnaie.
Les transactions non-définies sont des transactions de la blockChain n’utilisant que des données additionnelles pour envoyer des informations qui ne peuvent pas être qualifiées. Les transactions sont utilisées comme support d’une information non typée.

4.1. Les Définitions

Les définitions permettent de spécifier les types d’asset qui peuvent être utilisés et leurs cardinalités.

Eléments du diagramme	Description
	Asset Fermé : L’Asset est créé avec 500 unités. Aucune unité supplémentaire ne pourra être créée; toutes les unités possibles sont créées à la création de l’Asset.
	Asset Ouvert : L’Asset est créé avec 500 unités. L’autre cardinalité indique que le nombre d’unités peut augmenter en effectuant des requêtes de 100 unités.

4.2. Diagramme UD pour le use case Bibliothèque

Dans le diagramme Population Map, nous avons vu que seule la Bibliothèque Centrale (Central Library) était en mesure de créer des Assets (droit d’Issue). En regardant en détail le use case, on peut noter que 3 types d’Assets sont nécessaires :

• Le premier type d’Assets est Nouveau Livre “New Book”. Cet Asset représente un lot pour un même livre. Si le livre doit être acheté, à nouveau, plus tard, un nouvel Asset sera créé parce qu’il ne s’agira pas du même lot de livres. Ainsi, cet Asset est fermé et la quantité est définie, initialement, par la quantité de livres achetés.

{% responsive_image path: assets/images/post/moblo-fr/UD-Library.png alt:“UD-Library” %}

Figure 4-1 - UD - Bibliothèque

• Le second type d’Assets est la Réservation “Booking”. Une unité de cet Asset est utilisée pour représenter la réservation d’un livre particulier par un lecteur particulier dans une Bibliothèque particulière. A l’initialisation du système, le nombre de réservations à gérer simultanément ne peut pas être défini, l’Asset est donc laissé ouvert.

• Le dernier type d’Assets est le Retard “Delay”. Les unités de cet Asset sont envoyées aux Lecteurs pour leur indiquer qu’ils sont en retard pour rendre un livre donné. Comme pour la Réservation, le nombre total de Retards simultanés ne peut pas être définis à l’initialisation et il peut évoluer avec le temps, alors l’Asset est laissée ouvert.

Bien faire attention à la façon donc les Assets sont notés dans le diagramme UD. Pour “Booking” et “Delay”, les Assets sont déclarés une fois à l’initialisation de la plateforme et, après, les unités de l’Asset sont utilisées. Pour “New Book i”, la lettre “i” informe que plusieurs Assets peuvent être créés sur le même modèle, par exemple on peut imaginer que l’Asset “Ubik” est créé avec une quantité 5, que l’Asset “H2G2” est créé avec une quantité de 42, …

4.3. Diagramme UD pour le use case Forum

Le Forum est utilisé pour publier de nouveaux sujets et envoyer des commentaires relatifs aux sujets.

Figure 4-2 - UD - Forum

Un nouveau sujet peut être créé par le Créateur du Forum ou n’importe quel Editeur. Les unités d’un même Asset sont utilisées pour envoyer des commentaires sur le sujets. C’est-à-dire que l’Asset et ses unités poteront toutes les transactions relatives au sujet. La première transaction portera le sujet initial et les transactions suivantes porteront les commentaires.

Le use case est présenté ici dans un “monde parfait”. On pourrait imaginer des Assets supplémentaires comme “Warning” ou “Information”. Le cas est donc limité à la publication de sujets sans qualification particulière.

5. Business Transactions (BT), les “Transactions Métier”

Les parties précédentes donnaient une approche en lien avec l’architecture. Elles donnent les moyens de déterminer la population, l’architecture logicielle et l’architecture des données. Les business transactions offrent un point de vue plus en lien avec le métier.

Cette partie présente les transactions qui ont un sens pour la BlockChain. En considérant que la partie technique de la transaction est valide, une transaction peut porter des données dans la BlockChain qui peuvent être utilisées dans des cas non monétaires, donc les données métiers associées aux transactions sur la blockchain doivent être cohérentes.

5.1. Modélisation

Chaque transaction possède une origine et une destination. Chaque transaction peut porter une quantité variable de données métier associées.

Figure 5-1 - BT - Transaction Simple

Dans la transaction représentée, Alice envoie à Bob des unités de l’Asset Aj avec un complément de données dk en utilisant la transaction ti.

Figure 5-2 - BT - Transaction MultiSignée

Dans le cas d’une transaction depuis une adresse multisignée, l’origine de la transaction peut être indiquée explicitement. Dans la figure qui précède, Alice et Bob envoient à Carol, 10 unités de A5 et 6 unités de A12 en utilisant la transaction tz.

L’identification des transactions devient importante quand le projet nécessite que les transactions respectent un ordre précis, le flux de transactions peut alors être identifié. On n’écrit plus tz, mais t1, t2, t3, …

5.2. Le diagramme BT pour le use case Bibliothèque

La use case Bibliothèque présente un grand nombre de transactions possibles.

Figure 5-3 - BT - Bibliothèque - Inscription

Les Lecteurs utilisent un portail Web pour accéder au système d’information. Ainsi, quand un nouveau Lecteur souhaite s’enregistrer, il peut utiliser le portail Web. Dans la figure qui précède, la flèche est en pointillés pour indiquer qu’il ne s’agit pas d’une transaction de la BlockChain mais d’une action extérieure. La modélisation de telles transactions peut être utile pour décrire complètement le use case et rappeler l’importance du portail Web.

Figure 5-4 - BT - Bibliothèque - Distribution

La Bibliothèque Centrale (CL) crée des Assets et les unités d’Asset. Quand un livre est envoyé dans une Bibliothèque (L), la Bibliothèque Central (CL) doit envoyer l’unité d’Asset à la Bibliothèque (L).

Figure 5-5 - BT - Bibliothèque - Centralisation

Les livres peuvent être rendus dans n’importe quelle Bibliothèque.En cas de doublons, les livres supplémentaires doivent être envoyés à la Bibliothèque Centrale.

La réservation d’un livre particulier peut aussi être la raison d’un tel envoi, par exemple si un livre n’est disponible qu’en un seul exemplaire. Si quelqu’un souhaite le lire, alors le livre doit être transféré d’une Bibliothèque à une autre en passant par la Bibliothèque Centrale.

Quoiqu’il en soit, la BlockChain indique où est situé le livre disponible.

La centralisation suit le même principe que la distribution, sauf que, dans ce cas-ci, le livre est envoyé de la Bibliothèque (L) à la Bibliothèque Centrale (CL).

Figure 5-6 - BT - Bibliothèque - Emprunt

Un Lecteur (R) peut emprunter un livre. Le livre est alors pris de la Bibliothèque (Bibliothèque Centrale CL ou une autre Bibliothèque L) et envoyé au Lecteur. La transaction peut porter des informations comme la date de fin de l’emprunt.

Figure 5-7 - BT - Bibliothèque - Retour

Le cycle simple d’un emprunt de livre prend fin avec le retour du livre. Quand un Lecteur retourne un livre, l’unité (représentant le livre) est renvoyée à la Bibliothèque où le livre est rendu.

A ce niveau-ci de la description, le système d’emprunt de livres peut s’apparenter à un livre de compte qui permet de savoir, à tout moment, où se trouve un livre.

Figure 5-8 - BT - Bibliothèque - Réservation

La figure qui précède est séquentielle, les transactions sont numérotées de façon à indiquer l’ordre qui doit être suivi.

La Réservation d’un livre permet à un Lecteur de demander un livre particulier dans une Bibliothèque particulière. Il faut garder en mémoire que le Lecteur ne peut utiliser que le Portail Web et seule la Bibliothèque Central (CL) peut créer des Assets et des unités d’Asset.

Le Lecteur (R) effectue sa demande de réservation en utilisant le Portail Web. Une unité de l’Asset Réservation (K) est envoyée de la Bibliothèque Centrale (CL) jusqu’à la Bibliothèque (L) destination demandée par le Lecteur. La transaction porte les informations à propos de la Réservation (référence de livre, bibliothèque de destination, …).

A présent, le système sait que le livre est attendu dans une Bibliothèque en particulier. Soit le livre est déjà dans la bibliothèque et il n’y a rien à faire. Soit le livre est disponible dans une autre bibliothèque alors les batches doivent gérer l’envoi du livre à la bibliothèque où il a été réservé, par le biais d’une centralisation du livre vers la Bibliothèque Centrale puis de la distribution du livre vers la Bibliothèque de destination.

Quand le livre est disponible dans la Bibliothèque destination, cette Bibliothèque (L) envoie l’unité de Réservation (K) au Lecteur (R) pour lui notifier que le livre l’attend à la Bibliothèque. A la fin, lorsque le Lecteur (R) vient pour emprunter le livre, l’unité de Réservation (K) est renvoyée à la Bibliothèque Centrale (CL).

Il faut noter que la première étape de la Réservation est faite via le Portail Web. Il y a donc un ensemble de règles métier à implémenter dans le Portail Web. Dans cette partie, une règle peut préciser le nombre de Réservation qu’un même Lecteur peut faire au même moment. Mais, cette règle n’apparaît pas dans la modélisation BlockChain.

Figure 5-9 - BT - Bibliothèque - Retard

La dernière partie du cas est la gestion des Retards dans le retour des livres. Les transactions sont créées par les batches qui utilisent l’adresse de la Bibliothèque Centrale (CL) sur la base des informations de réservation. Quand un livre est réservé, la date de fin est spécifiée, le système peut aisément la retrouver et donc retrouver les livres empruntés pour lesquels la date est dépassée.

Dans ce cas, une unité de Retard (D) est envoyée au Lecteur (R) depuis la Bibliothèque Centrale (CL) avec une référence sur le livre qui est en retard.

Quand le Lecteur (R) ramène le livre, il envoie à la Bibliothèque (CL/L) l’unité du Livre (B) et l’unité de Retard (R).

5.3. Le diagramme BT pour le use case Forum

Le forum est un cas beaucoup plus simple dans lequel seules deux transactions peuvent être faites (ou envoyées) : créer un nouveau sujet et envoyer un commentaire sur un sujet existant.

Figure 5-10 - BT - Forum - Nouveau Sujet

La création d’un nouveau sujet consiste en la création d’un nouvel Asset. Cela peut être fait par le Créateur du Forum (FC) ou un Editeur (E). Quand un nouveau sujet est ouvert, la personne qui publie crée un nouvel Asset (Sni) et envoie une unité de l’Asset sur le Mur de Publication. La transaction porte le contenu de la publication qui peut être lu par toute personne ayant la possibilité de se connecter à la BlockChain.

Figure 5-11 - BT - Forum - Commentaire

Le Créateur d’un Asset est le propriétaire de cet Asset. Il est donc le seul à pouvoir créer de nouvelles unités de cet Asset.

Dans le cas du Forum, l’intérêt est de suivre les Sujets et les Commentaires sur les Sujets. C’est pour cette raison qu’un même Asset est utilisé pour le Sujet et les Commentaires sur le Sujet. Pour commenter une publication, les personnes ont besoin de demander une unité de l’Asset au Créateur de la publication.

Une Personne (P) qui souhaite commenter crée une transaction ne contenant que des données. Ces données indiquent quel est le Sujet qui sera commenté ainsi que la transaction précise qui sera commentée. La transaction est envoyée à l’adresse du Créateur du Sujet (FC/E).

Si le Créateur du Sujet décide d’autoriser le commentaire, il envoie à (P) une unité de l’Asset référencée dans la demande de commentaire.

A la fin, (P) peut envoyer son commentaire sur le Mur de Publication en utilisant l’unité d’Asset, en référençant la transaction à commenter et en donnant son commentaire.

Conclusion

Qu’en est-il des Smarts Contracts ? Un smart contract est un logiciel (parlons plutôt de script) directement inclus dans la BlockChain. Du point de vue de la modélisation, un smart contract est représenté par une adresse dans le diagramme Global Architecture et par des interactions avec le smart contract qui peuvent être définies dans le diagramme Business Transactions. Mais le contenu des smarts contracts eux-mêmes doit être décrit avec les algorithmes habituels comme n’importe quel logiciel.

Ce article propose une modélisation pour les 4 éléments les plus importants dans la mise en place d’un projet BlockChain. Cette modélisation doit être comprise par n’importe quelle personne pouvant être concernée par la mise en place du projet, depuis les commerciaux jusqu’aux développeurs. La modélisation délimite le contexte défini par la Blockchain et indique ce qui doit être mis en place du point de vue BlockChain.

{% responsive_image path: assets/images/post/moblo-fr/multichain-logo-248x48.png alt:“multichain-logo-248x48” %} MultiChain est une BlockChain testée qui intègre, assurément, toutes les caractéristiques présentées dans ce document.