WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Credit Scoring: L'octroi des Cartes bancaires (PFE)

( Télécharger le fichier original )
par Wissem TRABELSI Marwen ALLAGUY
Institut des Hautes Etudes de Carthage - Licence en Informatique Appliqué à la Gestion, parcours: Administration des Affaires 2009
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

Chapitre IV:

Conception

Ce chapitre a pour principal objectif de structurer et comprendre l'application et de modéliser le problème d'une façon orienté objet.

En effet, le modèle d'analyse détaille les cas d'utilisation et procède à une première répartition du comportement du système entre divers objets.

1 Conception du cas d'utilisation « s'authentifier »

1.1 Description textuelle du cas d'utilisation « s'authentifier »

Nom

Authentification

use case ID

UC001

Acteurs principaux

Employé : responsable client, responsable système, analyste

Acteurs secondaires

 

Description

L'employé saisie le nom d'utilisateur et le mot de passe, il sera dirigé soit vers gérer les demandes s'il est responsable client, soit vers gérer le système s'il est responsable service soit vers l'évaluation de la demande

Pré-conditions

Le système doit être ouvert et la connexion avec la base doit être effectué

Scénarios

1. L'employé saisi le nom d'utilisateur et le mot de passe

2. Le système vérifie s'ils sont corrects

2.1 Si les deux champs sont incorrects, un message d'erreur : veuillez vérifier le login et/ou le mot de passe

2.2 Si les deux champs sont corrects :

2.2.1 il sera dirigé vers « gérer les demandes » s'il est Responsable Client

2.2.2 il sera dirigé vers « gérer le système » s'il est Responsable Service

2.2.3 il sera dirigé vers « évaluation » s'il est analyste

Post-conditions

Le Responsable Client peut vérifier et modifier les informations du client

Le Responsable Service peut gérer le système

L'analyste peut évaluer les demandes

Priorité

Haute

Scénario alternatif

Le directeur peut ouvrir le système grâce à son login et mot de passe unique

1.2 Cas d'utilisation « s'authentifier » détaillé

Figure 14: Cas d'utilisation "s'authentifier"

2 Conception du cas d'utilisation « gérer le système » 2.1 Description textuelle du cas d'utilisation « gérer le système »

Nom

Gérer système

use case ID

UC002

Acteurs principaux

Responsable service

Acteurs secondaires

 

Description

Le responsable service gère les utilisateurs, la base de règle et les cartes

Pré-conditions

Le responsable service doit s'être authentifié

Scénarios

1. Le responsable service choisi de gérer soit les utilisateurs
soit la base de règle soit les cartes

2. Le responsable service peut ajouter ou supprimer les
utilisateurs ou leurs informations

3. Le responsable service choisie les informations à noter ainsi que leur pondérations

4. Le responsable service peut ajouter, supprimer ou modifier les cartes ainsi que leur score

Post-conditions

Les informations des utilisateurs, les cartes et les bases de règles sont mises à jour

Priorité

Haute

Scénario altérnatif

Le directeur peut ouvrir le système grâce à son login et mot de passe unique

2.2 Cas d'utilisation « gérer système » détaillé

Figure 15 : cas d'utilisation "gérer système"

2.3 Diagramme de séquence du cas d'utilisation « gérer le système »

s'autentifier

réponse

alt

mettre à jour

mettre à jour

mettre à jour

: Responsable
service

: interface
Authentification

: gérer cartes

: gérer
utilisateurs

: gérer base de
régle

Figure 16 : Digramme de séquence du cas d'utilisation " gérer système"

3 Conception du cas d'utilisation « Créer une nouvelle demande de carte»

3.1 Description textuelle du cas d'utilisation « Créer une nouvelle demande de carte»

Nom

Créer une nouvelle demande de carte

use case ID

UC003

Acteurs principaux

Client

Acteurs secondaires

 

Description

Le client s'authentifie, puis saisi ses informations

Pré-conditions

Le client doit être un client de la banque Le client doit s'être authentifié

Scénarios

1. Le client choisi entre entreprise ou particulier

2. Le client rempli le formulaire

3. Le client choisi la carte souhaité

Post-conditions

Le client a rempli le formulaire et le formulaire a été envoyé

Priorité

Haute

Scénario altérnatif

Le responsable client peut remplir les informations que le client n'a pas fournies

Nombehavional

 

Assomption

Le client doit avoir un compte à la banque

3.2 Cas d'utilisation « Créer une nouvelle demande de carte » détaillé

Figure 17 : cas d'utilisation "créer nouvelle demande"

3.3 Diagramme de séquence du cas d'utilisation « Créer une nouvelle demande de carte»

Figure 18 : diagramme de séquence du cas d'utilisation « créer nouvelle demande »

4 Conception du cas d'utilisation « Vérification»

4.1 Description textuelle du cas d'utilisation « Vérification»

Nom

Vérification

use case ID

UC004

Acteurs principaux

Responsable client

Acteurs secondaires

Système d'échange bancaire, SI de la banque

Description

Le responsable doit vérifier les informations de chaque demande, il compare le formulaire obtenu avec les informations du systeme d'echange bancaire et de la banque

Pré-conditions

Notification de chaque donnée collectée La demande est prête à être évaluée

Scénarios

1. le système fait appel à une fonction

2. le système fait appel aux notes des données utiles

 
 
 

Post-conditions

 

Priorité

Haute

Scénario altérnatif

Si la fonction choisie ne correspond pas aux données saisies, il y a retour à la page : « choisir fonction »

Nombehavional

Seule l'administrateur peut gérer les fonctions et les pondérations

Assomption

Le client doit avoir un compte à la banque

4.2 Cas d'utilisation « Vérification» détaillé

Figure 19 : cas d'utilisation « vérifier les données »

5 Conception du cas d'utilisation « Evaluation»

5.1 Description textuelle du cas d'utilisation « Evaluation»

Nom

Evaluation

use case ID

UC005

Acteurs principaux

Analyste

Acteurs secondaires

 

Description

L'analyste note les informations du client et lance le calcule du score

Pré-conditions

Les informations du client sont collectées par l'agent La demande est prête à être évaluée

Scénarios

7. L'analyste reçoit les informations pertinentes du client

8. L'analyste donne une note à chaque information

9. L'analyste lance le calcul du score

10. Le système calcul le score

11. Le système recommande 0, 1 ou plusieurs cartes aux client suivant le score obtenu et les cartes existantes

Post-conditions

Le score est calculé

Priorité

Haute

Scénario alternatif

 

Nombehavional

Seule le responsable système peut gérer les informations à noter et leur pondération

5.2 Cas d'utilisation « Evaluation» détaillé

Figure 20 : cas d'utilisation "évaluer la demande"

5.3 Diagramme de séquence du cas d'utilisation « Evaluation»

Figure 21 : Diagramme de séquence du cas d'utilisation " évaluer demande"

6 Conception cas d'utilisation général

7 Conception du diagramme de classe général

8 Conception du diagramme d'activité général

9 Conclusion

Cette analyse des différents cas d'utilisation nous a permis d'effectuer une spécification plus précise des besoins et nous a servi de base à une réflexion sur les mécanismes internes du système.

Ceci constitue une entrée essentielle pour la réalisation du modèle conceptuel du système que nous allons présenter dans le prochain chapitre.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Il ne faut pas de tout pour faire un monde. Il faut du bonheur et rien d'autre"   Paul Eluard