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.
|