Diagramme d'architecture du projet avec les conventions d'un diagramme de composants.

Terminal

C'est la partie représentant l'interface utilisateur du téléphone mobile.

Elle comporte le choix des produits, avec possibilité de les ajouter dans un panier et de valider ce panier pour procéder au paiement. Trois module la compose.

authentication

C'est le module responsable de l'authentification d'un utilisateur.

product

Ce module sert à la visualisation des produits à vendre par la boutique. Il se charge d'afficher la liste des produits et le panier lors d'un processus pré payement.

payment

Module à la charge du paiement d'un panier, il sert à générer les QR codes, afficher un lecteur de carte et d'appeler l'API lors d'un processus de transaction bancaire.

Coordinator

Ce module contiendra plusieurs parties :

• api_gateway : router de l'application, réorientant les différentes requêtes HTTP.
• mediator : module qui va dispatcher les notifications entre les différents module bank et shop lors des étapes de commandes et de paiement. Voici son diagramme de classe :

Ce schéma illustre de manière dynamique les différentes étapes gérées par le mediator :

Dans le scénario nominal :

• 1 et 2 : MediatorController notifie ShopController de la création d'une commande. Cette notification se fait via MediatorService, et transite grâce à ShopTransmitter.
• 3 et 4 : ShopController renvoie une réponse, via ShopTransmitter, à MediatorController
• 5 et 6 : MediatorController notifie BankController d'une nouvelle transaction. Bank gère la création de la transaction, la vérification des informations de paiement, la vérification de la solvabilité du compte, et le transfert de fond.
• 7 et 8 : BankController revoie une réponse, via BankTransmitter, à MediatorController
• 9, 10, 11, 12 : la mise à jour de la commande et de la transaction en base de données est faite.

Server

Shop

C'est la partie responsable de la gestion de la boutique. Elle assure la disponibilité des produits et la viabilité des commandes faîtes depuis le terminal.

Trois modules la compose.

order

Définit la commande passée et stocke l'état de la transaction bancaire.

cart

Définit le panier lors de l'achat.

product

Définit un produit en vente dans la boutique.

Bank

Cette partie simule une application bancaire. Elle permet de gérer les comptes utilisateur et de vérifier la viabilité d'une transaction bancaire lors d'un achat.

Trois modules la compose.

Les noms des modules commencent par : com.cashmanager.

Exemple : Pour le module account -> com.cashmanager.account

transaction

C'est un module central, il permet de gérer l'état d'une transaction et d'envoyer les informations nécessaires. il est décisionnaire lors d'un mouvement d'argent, il effectue les transactions d'argent entre les comptes.

Il sert aussi de point d'entré et de sortie de l'application pour prévenir un service extérieur du bon fonctionnement ou non de la transaction.

Fonctionnalités :

• Créditer un compte,
• Décréditer un compte,
• Prévenir lors d'un mouvement,
• Vérifier l'état global des transactions et créer des logs en lien avec elles.

account

Ce module sert à gérer la partie compte des clients de la banque. Il définit le profil d'un client et gère les différents comptes qu'il peut avoir.

Fonctionnalités :

• CRUD des comptes,
• Vérifier la véracité d'un compte,
• Bloquer un compte (si fraude).
• Effectuer un transfert d'argent entre deux comptes.

database

Ce module est centré sur la base de donnée de module parent bank. Il contient les entités dont a besoin l'application pour fonctionner. Il a également un dossier pour les mappers, fonctionnalités permettant de transformer les entités en DTO et inversement.

common

Ce module permet de regrouper les parties communes de l'application, il peut-être appelé mais n'a pas de dépendances à d'autres modules en son sein. Il se trouve à la même racine que le module bank.

Fonctionnalités :

• Modèles communs,
• Énumérations,
• Fonctions services globalisées.