Figure 39: Bloc 17

Figure 39: Bloc 17

5. IDENTIFICATION DES ACTEURS

UML n'emploie pas le terme d'utilisateur, mais d'acteur. Les acteurs d'un système sont les entités externes à ce système qui interagissent avec lui.

Les acteurs sont donc à l'extérieur du système et dialoguent avec lui. Ces acteurs permettent de cerner l'interface que le système va devoir offrir à son environnement. Oublier des acteurs ou en identifier de faux conduit donc nécessairement à se tromper sur l'interface et donc la définition du système à produire.

En se basant sur les besoins fonctionnels que j’ai extrait dans mon batch Proc*C et dans le but d’organiser ces interactions avec le système ces acteurs sont décrits comme suit :

Acteur

Admin

Rôle

C'est l'administrateur du système, il a le droit de faire toutes les actions affectées à l’acteur « User », et en plus il peut modifier dans toutes les interfaces là où il y a un champ de modification.

Provider C’est l’acteur secondaire ayant le droit de me donner l’autorisation de carte CCA Bilpay pour récupérer le numéro de la carte bancaire.

Tableau 3.1: Les acteurs Principaux

6. DIAGRAMMES DE CAS D’UTILISATION

Le diagramme de cas d'utilisation est un diagramme UML, il est utilisé pour donner une vision globale du comportement fonctionnel d'un système logiciel.

Un cas d'utilisation représente une unité discrète d'interaction entre un utilisateur (humain ou machine) et un système. Il est une unité significative de travail. Dans un diagramme de cas d'utilisation, les utilisateurs sont appelés acteurs (Actors), ils interagissent avec les cas d'utilisation (use cases).

Dans mon cas, j’ai un administrateur celui qui responsable de lancement du batch, ce dernier s'effectue d'une façon automatique sans intervention humaine. Dans mon script Pro*c, j’ai extrait 14 cases :

- Use case 1 : - Sélectionner les réservations qui correspondent au cas NS. - Use case 2 : - Création une ligne PR (dans la table pymts en utilisant les données de la ligne PP de la table pymts). - Use case 3 : - Vérifier l'éligibilité de la réservation - Use case 4 : - Calculer le montant de NS.

- Use case 5 : - Convertir la devise du No show fee amount.

- Use case 6 : - Comparer le no show fee amount avec prepaid amount. - Use case 7 : - Comparer la devise des frais de NS avec la devise de location. - Use case 8 : - Convertir le montant des frais de NS en devise de location.

- Use case 9 : - Mettre à jour la valeur des frais de NS. - Use case 10 : - Déterminer le moyen de paiement à facturer pour les frais de NS. - Use case 11 : - Vérifier les frais de NS sont à imputer à un compte professionnel. - Use case 12 : - Récupération de la devise du compte (de la table BUS_ACNTS). - Use case 13 : - Comparer la devise du business account est la même que celle de la location. - Use case 14 : - Convertir la devise du business account

- Use case 15 : - Récupération du numéro de la carte bancaire

- Use case 16 : - Faire un appel de l'autorisation de carte CCA bilpay - Use case 17 : - Créer d'une ligne NS (dans la table Payments) - Use case 18 : - Mettre à jour du statut de la réservation sur NS - Use case 19 : - Insérer un enregistrement (dans la table HIST_CHNGS pour la réservation d'entrée).