Vous êtes sur la page 1sur 160

Université de Tunis

Institut supérieur de Gestion

Projet de fin d’études :


Pour l’obtention de la licence fondamentale en Informatique de Gestion

Conception et réalisation d’une application de


gestion et suivi des contreparties de refinancement

Travail proposé et réalisé en collaboration avec :

Encadré par : Réalisé par :


Ahmed Badreddine Khadija Bouguerra
Chokri Kharrat Lina Esseghaier

Année universitaire : 2013/2014


Dédicaces
Ma reconnaissance se tourne en premier lieu vers Dieu le tout puissant.

Je dédie par la suite ce modeste travail

A l’homme de ma vie, mon exemple éternel, mon soutien moral et source de


joie et de bonheur, celui qui s’est toujours sacrifié pour me voir réussir,
A toi Mon père.
A la lumière de mes jours, la source de mes efforts, la flamme de mon cœur,
ma vie et mon bonheur,
A toi Ma mère.
A mes deux chers frères, mes anges gardiens et mes fidèles compagnons dans
les bons et les mauvais moments, Je vous souhaite un avenir plein de joie, de
bonheur, de réussite et de sérénité.

A mes très chers amis, votre affection et votre soutien m’ont été d’un
grand secours au long de ma vie professionnelle et personnelle.
A mon aimable binôme, sans qui ce projet n’aurait pas lieu, je ne
remercierai jamais assez dieu de t’avoir mise sur mon chemin.
Aux membres de mon honorable grande famille, mes oncles, mes tantes,
mes cousins et mes cousines que je chéris tant et qui m’ont guidé vers le bon
chemin.
A la famille « Esseghaier », qui m’ont accueillie à bras ouverts dans
leur famille,
Khadija Bouguerra
Dédicaces
Ma reconnaissance se tourne en premier lieu vers Dieu le tout puissant.
Je dédie par la suite ce modeste travail
A mon Père Aucune dédicace ne saurait exprimer l’amour, l’estime, le
respect que j’ai toujours eu pour toi. Rien au monde ne vaut tes efforts pour
mon éducation et mon bien être
A ma très chère mère la prunelle de mes yeux, la source de tendresse tu
n’as pas cessé de m’encourager et de prier pour moi. Tes prières m’ont été
d’un grand secours
A mon frère Rien ne suffit pour exprimer l’attachement, l’amour et
l’affection que je porte pour toi. Mon fidèle compagnon dans les moments les
plus délicats de cette vie mystérieuse.
A ma merveilleuse et exceptionnelle grand-mère maternelle qui a tant
sacrifié pour nous. A tous les membres de ma famille, petits et grands
A ma binôme Bien plus qu’une amie une sœur, qui m’a soutenu et
supporté dans les moments les plus difficiles Ce fut un grand plaisir de
travailler avec toi. Je souhaite une longue vie à notre amitié

A mes chers amis, En témoignage de l’amitié qui nous uni et des


souvenirs de tous les moments que nous avons passé ensemble, je vous dédie ce
travail

A l’agréable famille « Bouguerra » que je considère comme étant ma


propre famille

Lina Esseghaier
Remerciement
Nos sincères remerciements s’adressent en premier lieu à notre
encadreur Monsieur Ahmed Badreddine pour l’aide efficace qu’elle nous
a apporté dans l’élaboration de ce modeste travail. Nous avons pu
apprécier à sa juste valeur combien sa précieuse assistance a été
déterminante pour la réalisation de ce projet. Qu’elle trouve à travers ce
remerciement le signe de notre reconnaissance et notre profonde gratitude.

Nos vifs remerciements s’adressent aussi à Monsieur KHARRAT


CHOKRI, notre encadreur professionnel à la banque centrale de Tunisie
(BCT), qui malgré ses multiples occupations que lui imposent son poste a
trouvé le temps de s’occuper de nous et de répondre à nos questions.

Nous exprimons nos profonds respects à Monsieur HARBAOUI


ABDESSALEM responsable de la formation au sein de la direction
générale de système d’information (DGSI) pour son encadrement et son suivi
contenu de notre stage.
Table des matières
Table des matières
Chapitre I : Contexte général………………………………………………………..3
1. Introduction .......................................................................................................... 4

1. Présentation de l'organisme d'accueil ................................................................... 4

1.1. Historique de la BCT ........................................................................................ 4

1.2. Rôle de la BCT ................................................................................................. 4

1.3. Les pouvoirs de la BCT .................................................................................... 5

1.4. Missions de la BCT .......................................................................................... 5

1.5. Les organes de décision .................................................................................... 5

2. Direction Générale des Systèmes d’Information (D.G.S.I).................................. 5

2.1. Présentation de la Direction Générale des Systèmes d’Information ................ 5

2.2. Directions de la D.G.S.I.................................................................................... 5

2.3. Organigramme de la D.G.S.I ............................................................................ 6

2.4. Mission de la D.G.S.I ....................................................................................... 7

3. Etude de l'existant................................................................................................. 7

3.1. Description de l'existant.................................................................................... 7

3.1.1. Les crédits ................................................................................................... 7

3.1.2. Bon du trésor .............................................................................................. 9

3.1.3. Les contrôles à effectuer ........................................................................... 10

3.2. Le système existant ......................................................................................... 10

4. Etude du sujet ..................................................................................................... 10

4.1. Problématique ................................................................................................. 10

4.2. Etude des solutions possibles ......................................................................... 11


5. Besoins Fonctionnels et Besoins Non Fonctionnels .......................................... 11

5.1. Besoins Fonctionnels ...................................................................................... 11

5.1.1. Besoins Fonctionnels de la partie utilisateur BCT ................................... 11

5.1.2. Besoins Fonctionnels de la partie Administrateur .................................... 14

5.2. Besoins Non Fonctionnels .................................................................................. 14

6. Environnement logiciel du travail ...................................................................... 15

6.1. Logiciel de réalisation de conception ............................................................. 15

6.2. Outil de modélisation Power AMC ............................................................. 16

Présentation et concept de POWER AMC ............................................................ 16

Fonctionnalités principales de POWER AMC ...................................................... 16

Avantages de POWER AMC ................................................................................ 16

6.3. Architecture mise en place ............................................................................. 17

7. Conclusion ........................................................................................................ 18

Chapitre II: Spécification des exigences……………………………………………19


1. Introduction ........................................................................................................ 20

2. Spécification générale des exigences ................................................................. 20

2.1. Identification des acteurs ................................................................................ 20

2.2. Identification des cas d’utilisation .................................................................. 20

2.3. Affectation des priorités aux cas d’utilisation : .............................................. 22

2.4. Raffinement des Cas d’utilisation................................................................... 22

2.4.1. Raffinement du Cas d’utilisation « S’authentifier » ................................. 22

2.4.2. Raffinement du cas d’utilisation Gestion du portefeuille de crédits ........ 24

2.4.3. Raffinement du cas d’utilisation Gestion encours bon trésor ................... 30

2.4.4. Raffinement du cas d’utilisation Gestion garantie crédit ......................... 38

2.4.5. Raffinement du cas d’utilisation Gestion garantie bon trésor .................. 46

2.4.6. Raffinement du cas d’utilisation Gestion référentiel crédit ...................... 55

2.4.7. Raffinement du cas d’utilisation Gestion référentiel bon du trésor .......... 59


2.4.8. Raffinement du cas d’utilisation Gestion référentiel client ...................... 63

2.4.9. Raffinement du cas d’utilisation Gestion référentiel banque ................... 67

2.4.10. Raffinement du cas d’utilisation Gestion opération de refinancement... 72

2.4.11. Raffinement du cas d’utilisation Gestion utilisateurs ............................. 73

3. Définition des opérations systèmes .................................................................... 78

4. Conclusion .......................................................................................................... 80

Chapitre III: Conception et analyse………………………………………………..81


1. Introduction ........................................................................................................ 82

2. Analyse des cas d’utilisation .............................................................................. 82

2.1. Analyse du cas « Authentification » ............................................................... 82

2.1.1. Prototype de l’interface de l’authentification ........................................... 82

2.1.2. Diagramme de classe participante du cas de l’Authentification .............. 83

2.1.3. Diagramme de Séquence détaillé du cas de l’Authentification ................ 84

2.2. Analyse du cas « Gestion Portefeuille de crédits » ........................................ 84

2.2.1. Prototypes des interfaces du cas Gestion Portefeuille de crédits ............. 84

2.2.2. Diagramme de classe Participante du cas Gestion Portefeuille de crédits 86

2.2.3. Diagramme de séquence détaillé du cas Gestion Portefeuille de crédits . 87

2.3. Analyse du cas « Gestion Encours Bon du trésor » ........................................ 89

2.3.1. Prototypes des interfaces du cas Gestion Encours Bon du trésor ............. 89

2.3.2. Diagramme de classe participante du cas Gestion Encours bon du trésor 90

2.3.3. Diagramme de séquence détaillé du cas «Gestion encours Bon du trésor »


.................................................................................................................. 91

2.4. Analyse du cas « Gestion Garanties crédits »................................................. 93

2.4.1. Prototype du cas « Gestion Garanties crédits » ........................................ 93

2.4.2. Diagramme de classe participante du cas Gestion garanties crédits ........ 94

2.4.3. Diagramme de séquence détaillé du cas « Gestion Garanties Crédits »... 95

2.5. Analyse du cas « Gestion Garanties Bons du trésor » .................................... 96

2.5.1. Prototype de l’interface du cas « Gestion garanties Bons du trésor » ...... 96


2.5.2. Diagramme de classe participante du cas « Gestion Garanties Bons du
trésor » 97

2.5.3. Diagramme de Séquence détaillée du cas « Gestion Garanties bons du


trésor » 98

2.6. Analyse du cas « Gestion Référentiel Banques » ........................................... 99

2.6.1. Prototypes des interfaces du cas Gestion Référentiel Banques ................ 99

2.6.2. Diagramme de classe participante du cas « Gestion Référentiel Banques »


100

2.6.3. Diagramme de séquence détaillé du cas « Gestion Référentiel Banques »


100

2.7. Analyse du cas « Gestion Référentiel Bons Du trésor »............................... 102

2.7.1. Prototypes des interfaces du cas « Gestion Référentiel Bons du Trésor 102

2.7.2. Diagramme de classe participante du cas « Gestion Référentiel Bon du


trésor » 103

2.7.3. Diagramme de séquence détaillé du cas « Gestion Référentiel Bons du


trésor » 104

2.8. Analyse du cas « Gestion Référentiel Clients » ........................................... 106

2.8.1. Prototypes des interfaces du cas « Gestion Référentiel Clients » .......... 106

2.8.2. Diagramme de classe participante du cas « Gestion Référentiel Clients » ..


................................................................................................................ 107

2.8.3. Diagramme de séquence détaillé du cas « Gestion Référentiel Clients » ....


................................................................................................................ 108

2.9. Analyse du cas « Gestion Référentiel crédits » ............................................ 110

2.9.1. Prototypes des interfaces du cas « Gestion Référentiel Crédits » .......... 110

2.9.2. Diagramme de classe participante du cas « Gestion Référentiel crédits » ...


................................................................................................................ 111

2.9.3. Diagramme de séquence détaillé du cas « Gestion Référentiel Crédits » ....


................................................................................................................ 112

2.10. Analyse du cas « Gestion des utilisateurs » .............................................. 114


2.10.1. Prototypes des interfaces du cas de « Gestion des utilisateurs » .......... 114

2.10.2. Diagramme de classe participante du cas « Gestion des utilisateurs ». 115

2.10.3. Diagramme de séquence détaillé du cas « Gestion des utilisateurs »... 115

2.11. Analyse du cas « Consulter Opération de refinancement » ...................... 117

2.11.1. Prototypes des interfaces du cas « Consulter Opération de


refinancement » .............................................................................................................. 117

2.11.2. Diagramme de classe participante du cas « Consulter Opération de


refinancement » .............................................................................................................. 117

2.11.3. Diagramme de séquence détaillé du cas « Consulter Opération de


refinancement » .............................................................................................................. 118

3. Présentation du diagramme de classe global .................................................... 119

4. Conclusion ........................................................................................................ 121

Chapitre IV: Implémentation……………………………………………………..122


1. Introduction ...................................................................................................... 123

2. Génération des tables ....................................................................................... 123

3. Diagramme de déploiement ............................................................................. 127

3. Développement de l’application....................................................................... 128

3.1. Système de gestion de bases de données relationnelle ORACLE : .......... 128

3.2. Outil de développement Oracle Developer Forms .................................... 129

3.3. Outil d’administration TOAD ................................................................... 129

4. Les interfaces de développement ..................................................................... 130

4.1. Interface de l’Authentification...................................................................... 130

4.2. Interface du Menu Principal ......................................................................... 130

4.3. Interface de la Gestion du portefeuille de crédits ......................................... 131

4.4. Interface de la Gestion de l’encours bon du trésor ....................................... 132

4.5. Interface de la gestion des garanties Crédits ................................................ 134

4.6. Interface de la Gestion des garanties bons du trésor .................................... 135

4.7. Interfaces de la gestion du référentiel Banques : .......................................... 136


4.8. Interfaces de la gestion référentiel Bons du trésor ....................................... 137

4.9. Interfaces de la gestion du Référentiel Clients ............................................. 138

4.10. Interfaces de gestion Référentiel Crédits .................................................. 139

................................................................................................................................ 140

4.11. Interfaces de gestion des utilisateurs : ...................................................... 140

5. Conclusion ........................................................................................................ 141


Table des figures
Figure 1 Organigramme de la D.G.S.I ........................................................................... 6
Figure 2 Schéma du processus de modélisation ........................................................... 16
Figure 3 Power AMC 15.1[4] ....................................................................................... 17
Figure 4 Architecture 3 tiers [6] ................................................................................... 18
Figure 5 Diagramme de cas d’utilisation initial ........................................................... 21
Figure 6 Raffinement du Cas d’utilisation « S’authentifier » ...................................... 23
Figure 7 Diagramme Séquence Système « S’authentifier » ......................................... 24
Figure 8 Raffinement du Cas d’utilisation « Gérer portefeuille de crédits » ............... 24
Figure 9 Diagramme Séquence système de l'ajout d'un crédit au portefeuille ............. 25
Figure 10 Diagramme séquence système de la consultation d'un crédit du portefeuille
.................................................................................................................................................. 27
Figure 11 Diagramme Séquence système de la modification d'un crédit du portefeuille
.................................................................................................................................................. 28
Figure 12 Diagramme séquence système de la sélection des tombées ......................... 29
Figure 13 Diagramme séquence système de la suppression d'un crédit du portefeuille
.................................................................................................................................................. 30
Figure 14 Raffinement du cas d'utilisation "Gérer encours bon du trésor" .................. 31
Figure 15 Diagramme séquence système de l'ajout d'un bon du trésor ........................ 32
Figure 16 Diagramme séquence système de la consultation d'un bon du trésor .......... 34
Figure 17 Diagramme séquence système de suppression d'un bon du trésor ............... 35
Figure 18 Diagramme séquence système de modification d'un bon du trésor ............. 36
Figure 19 Diagramme séquence système de vérification de l'échéance d'un bon du
trésor ......................................................................................................................................... 38
Figure 20 Raffinement du cas d'utilisation "Gérer garantie crédit" ............................. 39
Figure 21 Diagramme séquence système de l'ajout d'une garantie crédit ................... 41
Figure 22 Diagramme séquence système de modification d'une garantie crédit.......... 42
Figure 23 Diagramme séquence système de consultation d'une garantie crédit .......... 43
Figure 24 Diagramme séquence système de suppression d'une garantie crédit ........... 44
Figure 25 Diagramme séquence système de consultation d'une opération de
refinancement ........................................................................................................................... 46
Figure 26 Raffinement du cas "Gestion garanties bon du trésor" ................................ 47
Figure 27 Diagramme séquence système de l'ajout d'une garantie bon du trésor ........ 49
Figure 28 Diagramme séquence système modification d'une garantie bon du trésor .. 50
Figure 29 Diagramme séquence sytème consulter garantie bon du trésor ................... 52
Figure 30 Diagramme séquence système Supprimer garantie bon du trésor ............... 53
Figure 31 Diagramme séquence système consulter opération de refinancement ......... 55
Figure 32 Raffinement du cas "Gestion référentiel crédit" .......................................... 56
Figure 33 Diagramme séquence système ajouter crédit au référentiel ......................... 57
Figure 34 Diagramme séquence système consulter crédit ........................................... 58
Figure 35 Diagramme séquence système modifier crédit du référentiel ...................... 59
Figure 36 Raffinement du sous cas "Gestion référentiel bon du trésor" ...................... 60
Figure 37 Diagramme séquence système ajouter bon du trésor au référentiel ............. 61
Figure 38 Diagramme séquence système consulter un bon du trésor du référentiel ... 62
Figure 39 Diagramme séquence système modifier bon du trésor du référentiel .......... 63
Figure 40 Raffinement du cas "Gestion référentiel client"........................................... 64
Figure 41 Diagramme séquence système ajouter client au référentiel ......................... 65
Figure 42 Diagramme séquence système Consulter client du référentiel .................... 66
Figure 43 Diagramme séquence système Modifier un client du référentiel ................. 67
Figure 44 Raffinement du cas "Gestion Référentiel banques" ..................................... 68
Figure 45 Diagramme séquence système Ajouter banque au référentiel ..................... 69
Figure 46 Diagramme séquence système Consulter banque ........................................ 70
Figure 47 Diagramme séquence système Modifier banque ......................................... 71
Figure 48 Raffinement du cas "Consulter refinancement" ........................................... 72
Figure 49 Diagramme séquence système Consulter opération refinancement ............. 73
Figure 50 Raffinement du cas "Gestion des utilisateurs" ............................................. 74
Figure 51 Diagramme séquence système Ajouter utilisateur ....................................... 75
Figure 52 Diagramme séquence système Consulter utilisateur .................................... 76
Figure 53 Diagramme séquence système Modifier utilisateur ..................................... 77
Figure 54 Diagramme séquence système Supprimer utilisateur .................................. 78
Figure 55: Liste des opérations Système ...................................................................... 79
Figure 56 Liste des opérations système structurées en interfaces ................................ 80
Figure 57 Prototype de l'interface de l'authentification ................................................ 83
Figure 58 Diagramme de classe participante de l'Authentification .............................. 83
Figure 59 Diagramme séquence détaillé de l'authentification ...................................... 84
Figure 60 Prototype de l'interface "Ajouter crédit au portefeuille" ............................ 85
Figure 61 Prototype de l'interface "Consulter crédit du portefeuille" .......................... 85
Figure 62 Prototype de l'interface "Sélection des tombées" ......................................... 86
Figure 63 Diagramme de classe participante "Gestion portefeuille de crédits" ........... 87
Figure 64 Diagramme séquence détaillé "Gestion portefeuille crédits" ....................... 88
Figure 65 Prototype de l'interface Ajouter bon du trésor ............................................. 89
Figure 66 Prototype de l'interface "Consulter bon du trésor"....................................... 90
Figure 67 Prototype de l'interface "Vérifier échéance bon du trésor" .......................... 90
Figure 68 Diagramme classe global "Gestion encours bon du trésor" ......................... 91
Figure 69 Diagramme séquence detaillé "Gestion encours bon du trésor" .................. 92
Figure 70 Prototype de l'interface "Gestion garanties crédits" ..................................... 93
Figure 71 Diagramme classe participante "Gestion garanties crédits"......................... 94
Figure 72 Diagramme séquence détaillé "Gestion garantie crédits" ............................ 95
Figure 73 Prototype de l'interface "Gestion garantie bon du trésor" ............................ 96
Figure 74 Diagramme de classe participante "Gestion garanties bon du trésor" ......... 97
Figure 75 Diagramme séquence détaillé "Gestion garanties Bon du trésor" ............... 98
Figure 76 Prototype de l'interface « Ajouter banque » ................................................. 99
Figure 77 Prototype de l'interface "Consulter banque" ................................................ 99
Figure 78 Diagramme de classe participante "Gestion référentiel banque" ............... 100
Figure 79 Diagramme séquence détaillé "Gestion référentiel banque" ...................... 101
Figure 80 Prototype de l'interface "Ajouter bon du trésor" ........................................ 102
Figure 81 Prototype de l'interface "Consulter bon du trésor"..................................... 103
Figure 82 Diagramme de classe participante "Gestion référentiel Bon du trésor" ..... 104
Figure 83 Diagramme séquence détaillé "Gestion référentiel bon du trésor" ............ 105
Figure 84 Prototype de l'interface "Ajouter client" .................................................... 106
Figure 85 Prototype de l'interface "Consulter client" ................................................. 107
Figure 86 Diagramme de classe participante "Gestion référentiel Client" ................. 108
Figure 87 Diagramme séquence détaillé "Gestion référentiel clients" ....................... 109
Figure 88 Prototype de l'interface "Ajouter crédit" .................................................... 110
Figure 89 Prototype de l'interface "Consulter crédit"................................................. 111
Figure 90 Diagramme de classe participante "Gestion référentiel crédits" ................ 112
Figure 91 Diagramme séquence détaillé "Gestion référentiel crédits" ....................... 113
Figure 92 Prototype de l'interface "Ajouter utilisateur" ............................................. 114
Figure 93 Prototype de l'interface "Consulter utilisateur" .......................................... 114
Figure 94 Diagramme de classe participante "Gestion utilisateurs" .......................... 115
Figure 95 Diagramme séquence détaillé "Gestion utilisateurs" ................................. 116
Figure 96 Prototype de l'interface "Consulter opération de refinancement" .............. 117
Figure 97 Diagramme de classe participante "Consulter opération de refinancement"
................................................................................................................................................ 118
Figure 98 Diagramme séquence détaillé "Consulter opération de refinancement" .... 118
Figure 99 Diagramme de classe global ...................................................................... 120
Figure 100 Diagramme de déploiement ..................................................................... 128
Figure 101 Toad For Oracle ....................................................................................... 129
Figure 102 Interface de l'authentification ................................................................... 130
Figure 103 Interface du menu principal ..................................................................... 131
Figure 104 Interface "Ajouter crédit au portefeuille" ................................................. 131
Figure 105 Interface "Consulter un crédit du portefeuille" ........................................ 132
Figure 106 Interface de Sélection des tombées .......................................................... 132
Figure 107 Interface "Ajouter bon du trésor dans l'encours" ..................................... 133
Figure 108 Interface "Consulter un bon du trésor de l'encours" ................................ 133
Figure 109 Interface "Vérifier échéance bon du trésor" ............................................. 134
Figure 110 Interface "Gestion garanties crédits" ........................................................ 135
Figure 111 Interface "Gestion garanties bon du trésor" ............................................. 136
Figure 112 Interface "Ajouter banque" ...................................................................... 137
Figure 113 Interface "Consulter banque" ................................................................... 137
Figure 114 Interface "Ajouter bon du trésor" ............................................................. 138
Figure 115 Interface "Consulter bon du trésor".......................................................... 138
Figure 116 Interface "Ajouter client" ......................................................................... 139
Figure 117 Interface "Consulter client" ...................................................................... 139
Figure 118 Interface "Ajouter crédit" ......................................................................... 140
Figure 119 Interface "Consulter crédit"...................................................................... 140
Figure 120 Interface "Ajouter Utilisateur" ................................................................. 141
Figure 121 Interface "Consulter Utilisateur" .............................................................. 141
Liste des tableaux
Tableau 1 Tableau des procédures actuelles ................................................................ 10
Tableau 2 Affectation des priorités aux cas d’utilisation ............................................. 22
Tableau 3 Scénario de l’authentification ...................................................................... 23
Tableau 4 Scénario Ajouter un crédit au portefeuille ................................................... 25
Tableau 5 Scénario de la Consultation d'un crédit du portefeuille ............................... 26
Tableau 6 Scénario de la modification d'un crédit du portefeuille ............................... 27
Tableau 7 Scénario de la sélection des tombées ........................................................... 28
Tableau 8 Scénario de suppression d'un crédit ............................................................. 29
Tableau 9 Scénario de l'ajout d'un bon du trésor .......................................................... 31
Tableau 10 Scénario de la consultation d'un bon du trésor .......................................... 33
Tableau 11 Scénario de suppression d'un bon du trésor ............................................... 35
Tableau 12 Scénario de modification d'un bon du trésor ............................................. 36
Tableau 13 Scénario de vérification de l'échéance d'un bon du trésor ......................... 37
Tableau 14 Scénario ajouter garantie crédit ................................................................. 40
Tableau 15 Scénario de modification d'une garantie crédit .......................................... 41
Tableau 16 Scénario de consultation d'une garantie crédit .......................................... 43
Tableau 17 Scénario de suppression d'une garantie crédit ........................................... 44
Tableau 18 Scénario de consultation d'une opération de refinancement ...................... 45
Tableau 19 Scénario de l'ajout d'un bon du trésor ........................................................ 48
Tableau 20 Scénario de modification d'une garantie bon du trésor .............................. 49
Tableau 21 Scénario de consultation d'une garantie bon du trésor .............................. 51
Tableau 22 Scénario de suppression d'une garantie bon du trésor ............................... 52
Tableau 23 Scénario Consulter opération refinancement ............................................. 54
Tableau 24 Scénario de l'ajout d'un crédit au référentiel .............................................. 56
Tableau 25 Scénario de consultation d'un crédit du référentiel .................................... 57
Tableau 26 Scénario de modification d'un crédit ......................................................... 59
Tableau 27 Scénario de l'ajout d'un bon du trésor ........................................................ 60
Tableau 28 Scénario de consultation d'un bon du trésor du référentiel ........................ 61
Tableau 29 Scénario de modification d'un bon du trésor du référentiel ....................... 63
Tableau 30 Scénario de l'ajout d'un client au référentiel .............................................. 64
Tableau 31 Scénario Consulter client ........................................................................... 65
Tableau 32 Scénario Modifier un client du référentiel ................................................. 66
Tableau 33 Scénario Ajouter banque au référentiel ..................................................... 68
Tableau 34 Scénario consulter banque ......................................................................... 69
Tableau 35 Scénario Modifier banque ......................................................................... 71
Tableau 36 Scénario Consulter opération de refinancement ........................................ 72
Tableau 37 Scénario Ajouter utilisateur ....................................................................... 74
Tableau 38 Scénario Consulter utilisateur .................................................................... 75
Tableau 39 Scénario Modifier utilisateur ..................................................................... 76
Tableau 40 Scénario Supprimer Utilisateur ............................................................... 77
Tableau 41 Liste des tables de la base de données ..................................................... 123
Introduction

Introduction Générale
Depuis que le monde est monde, on est sans cesse témoins de nouvelles technologies
plus révolutionnaires les unes que les autres. Et le domaine de l’informatique n’est pas
épargné de cette évolution constante. En effet, c’est le domaine qui connait le plus de
croissance. Chaque jour, de nouvelles technologies percent le marché. On cite entre autres les
nouvelles méthodologies de conception et des langages de développement apparaissant pour
résoudre les problèmes existants et dépasser les limites des versions antérieures.
Ces développements se combinent avec les simplifications administratives générales et
les services qui s’exercent dans un établissement bancaire dans notre cas.
Le présent rapport est un projet de fin d’étude réalisé en vue de l’obtention d’une
licence en Informatique de gestion. Ce rapport a été réalisé à la suite d’un stage de trois mois
au sein de la Banque Centrale de Tunisie.
Le sujet que nous aurons proposé concerne « la gestion et le suivi des contreparties
de refinancement ». Il nous a été demandé d’effectuer la conception et la réalisation d’une
application permettant la prise en charge et le suivi d’un portefeuille de créances éligibles à
une opération de refinancement et un encours de bons du trésor déclarés par la Société
Tunisienne Interprofessionnelle de Compensation des Valeurs Mobilières (STICODEVAM),
ainsi les garantis présentés par les banques en contrepartie d’une opération de refinancement
sur le marché monétaire et aussi les référentiels de ses garantis présentés.
Pour ce faire, nous adapterons « UML » comme langage de modélisation pour ce
projet, et concernant le développement de l’application, nous utiliserons les outils de
développement « ORACLE ».
Le présent rapport comporte quatre chapitres :
Dans le premier chapitre intitulé « Contexte général », nous allons présenter le cadre
de notre stage à savoir La Banque Centrale de Tunisie. Une description du système actuel
accompagnée de la problématique nous mènera à la proposition de notre solution.
Ensuite, nous identifierons les besoins fonctionnels et non fonctionnels de notre projet,
l’approche utilisée pour la conception, et enfin la méthodologie de l’architecture de travail
adoptée.

Page 1
Introduction

Dans le second chapitre intitulé « Spécification des exigences », nous allons identifier
les acteurs du système, le diagramme de cas d’utilisation global puis raffiné et nous
enchaînerons par la présentation des scénarios et le diagramme de séquence système de
chaque cas.
Le troisième chapitre « Conception et Analyse » aura pour but de faire l’analyse
détaillée et complète des cas d’utilisation identifiés dans le chapitre précédent. Nous
procèderons comme suit : on présente une maquette pour chaque interface de notre
application suivi d’un diagramme de classe participante et enfin un diagramme de séquence
détaillé. Vers la fin de ce chapitre, nous devrons établir le diagramme de classe global qui va
nous permettre d’identifier les différentes entités du système.
Dans le dernier chapitre, nous porterons sur l’implémentation de la solution proposée
en donnant un aperçu sur l’environnement technique de développement, le cycle de vie
adopté, la création de la base de données, ainsi que la présentation des interfaces réalisées.

Page 2
Chapitre I : Contexte Général

Chapitre I :
Contexte
Général

Page 3
Chapitre I : Contexte Général

1. Introduction
Dans ce chapitre, nous allons exposer en premier lieu le cadre de notre stage.
Nous commençons par formuler une présentation de notre organisme d’accueil ainsi que la
direction qui nous a reçues. Ensuite, nous enchaînons avec l’étude de l’existant qui nous
mènera à dégager notre problématique.
Et enfin, nous formulerons les besoins fonctionnels et non fonctionnels qui vont nous
permettre de capturer les cas d’utilisation nécessaires à notre projet.
1. Présentation de l'organisme d'accueil
1.1.Historique de la BCT
La Banque Centrale de Tunisie a vu le jour deux ans après l’Independence du pays.
Elle a été créée par la loi n°58-90 du 19 Septembre 1958.
C’est un établissement public national doté de la personnalité civile et de l’autonomie
financière. La direction des affaires de la Banque Centrale est exercée par un gouverneur
nommé par décret. Ce gouverneur est assisté par un Vice-gouverneur placé sous son autorité
immédiate et chargé de veiller sur tous les services de la Banque centrale. [1]
La BCT dispose de onze comptoirs, répartis sur tout le territoire national, qui la
représentent au niveau régional.
Ces comptoirs rapprochent les services de la BCT des opérateurs économiques et
favorisent le développement de la bancarisation des régions. Ils couvrent également les
besoins des agences bancaires, des recettes PTT et du trésor public en retraits et en
versements de billets de banque et pièces de monnaie et collectent à travers le pays
l’information économique et financière à l’effet de procéder à une analyse de la conjoncture
au niveau de la région.
1.2.Rôle de la BCT
Le rôle principal de la BCT est de coordonner entre plusieurs organismes, aussi bien à
l’intérieur du pays qu’à l’extérieur. La BCT présente le centre d’affluence d’une classe
importante d’informations et guide la politique de l’état en matière de change extérieur. Elle
participe à l’orientation de l’économie de la production en fonction des objectifs de la
politique économique et sociale du pays.
Ce rôle important la met en relation avec plusieurs organismes tels que la douane, le
ministère des finances, les ministères de l’économie, les administrations, les universités etc.

Page 4
Chapitre I : Contexte Général

1.3.Les pouvoirs de la BCT


Afin de remplir son rôle convenablement, la BCT dispose d’un pouvoir de
réglementation (gestion comptable et normes prudentielles), d’un pouvoir d’information
(rapport d’activité auprès des commissaires aux comptes) et d’un pouvoir d’intervention
(organisation des concours des banques) selon la loi n°94-25 du 7 Janvier 1994.
1.4.Missions de la BCT
La mission principale de la BCT consiste à défendre la valeur de la monnaie et de
veiller à sa stabilité.
En effet, elle contrôle la circulation monétaire et la distribution du crédit et veille au
bon fonctionnement des systèmes bancaire et financier. Les établissements bancaires et
financiers peuvent être amenés à fournir toutes les statistiques et les informations que la
Banque Centrale juge utiles pour connaître l’évolution du crédit et de la conjoncture
économique. De plus, elle est chargée de la centraliser les risques bancaires et de les
communiquer aux établissements bancaires et financiers. [2]
1.5.Les organes de décision
La direction, l’administration et la surveillance de la BCT sont sous la responsabilité
du gouverneur. Il est assisté dans sa tâche par un vice-gouverneur et un conseil
d’administration.
Le gouverneur: Il assure la direction des affaires de la banque car il représente la
banque centrale auprès des pouvoirs publics, banques, et organismes financiers
internationaux.
Le vice-gouverneur: Il est placé sous l’autorité directe du gouverneur. Il est chargé de
veiller en permanence à la bonne marche de tous les services de la banque.
Le conseil d’administration: Il assure l’administration de la banque. Il est composé
du gouverneur, du vice-gouverneur, de huit conseillés et d’un censeur chargé de la
surveillance de la banque.
2. Direction Générale des Systèmes d’Information (D.G.S.I)
2.1.Présentation de la Direction Générale des Systèmes d’Information
Le département informatique au sein de la B.C.T est représenté par la Direction
Générale des Systèmes d’Information.
2.2.Directions de la D.G.S.I
La direction générale des systèmes d’information est composée de trois directions :
- Direction Etude et Développement (DED).

Page 5
Chapitre I : Contexte Général

- Direction Sécurité Informatique (DSI).


- Direction Infrastructure, Informatique et Télécommunication (DIIT).
2.3.Organigramme de la D.G.S.I
L’organigramme de la DGSI est illustré dans la figure 1:

Figure 1 Organigramme de la D.G.S.I


Page 6
Chapitre I : Contexte Général

2.4.Mission de la D.G.S.I
La Direction Générale des Système d’Information est chargée de concevoir le système
d’information de la banque et d’établir le plan d’informations en fonction des besoins des
utilisateurs et des options arrêtées par le comité informatique. Elle assure, par ailleurs,
l’évaluation harmonieuse des applications, la gestion des équipements informatiques et la
sécurité informatique.
Cependant, la direction présente un certain nombre de problèmes. En effet, plusieurs
opérations sont accomplies manuellement, ce qui rend le travail assez long et pénible.
D'autant plus que le système existant est assez complexe et présente beaucoup d'insuffisances.
3. Etude de l'existant
3.1.Description de l'existant
La banque centrale de Tunisie (BCT) se réserve de prendre à son compte certaines
opérations de refinancement lorsqu’elle jugera nécessaire pour assurer l’équilibre du marché.
Une opération de refinancement représente une intervention de la banque centrale de
Tunisie au profit des banques pour fournir liquidités et faciliter leurs trésoreries.
L’intervention de la BCT peut prendre les formes suivantes :
Injection : Dans le cadre de l’équilibre monétaire, la BCT intervient pour fournir des
liquidités, à la demande des banques, sur le marché monétaire. Cette intervention permet au
taux du marché de se stabiliser et de ne plus croitre.
La BCT informe les banques qu’elle est prête à fournir des liquidités avec le taux du
marché.
On remarque avec cette opération que le taux est fixé par la BCT.
Appel d’offre positif : la BCT détermine périodiquement, en fonction de l’évolution
de la liquidité des banques, le volume de la monnaie centrale qu’elle est disposée à fournir.
A cet effet la BCT informe les banques de dépôts et d’investissement de son intention
d’alimenter en liquidité le marché sous forme d’appel d’offre.
Pension à 7 jours : la BCT interviendra sur le marché monétaire pour fournir des
liquidités sous forme de prise en pension pour une durée variant entre un et sept jours.
La banque centrale de Tunisie admet, en contrepartie des opérations de refinancement
des banques sur le marché monétaire, les effets publics négociables(les bons du trésor) et
les crédits offerts par les banques pour les entreprises et les particuliers.
3.1.1. Les crédits
Il s’agit des crédits offerts par les banques pour les entreprises et les particuliers.

Page 7
Chapitre I : Contexte Général

Les banques déclarent mensuellement les encours de crédits courants en précisant la


date de l’encours du crédit et le montant de l’encours (le montant reste à payer).
Les banques tiendront la Banque Centrale de Tunisie informée des règlements par
anticipation ou de la détérioration de la solvabilité des bénéficiaires de crédits refinancés.
Les crédits dispensés par les banques conformément aux normes fixées par le titre 2 de
la circulation n°87-47 du 23 décembre 1987, à l’exception de ceux visés à ses articles 14 et 14
bis, peuvent être admis par la Banque Centrale de Tunisie.
Les crédits peuvent avoir trois formes :
Les crédits à court terme :
Ce sont :
 Les crédits de cultures saisonnières
 Les crédits de compagne
 Les crédits de démarrage « huile d’olive »
 Avances sur marchandises
 Les crédits finançant l’acquisition, le transport et le stockage des fourrages en
sec et des bouchons de son
 Les crédits financement de stocks
 Les crédits de préfinancement des exportations
 Crédit non-mobilisable
 Avances sur créances administratives
 Escompte commercial sur l’étranger et mobilisation de créances nées sur
l’étranger
 Refinancement de marché publics
 Escompte commercial sur la Tunisie
Les crédits à moyen terme :
Les crédits à moyen terme sont généralement consentis pour le financement des
investissements, leur durée est fixée à un maximum de 7ans. Ce sont :
 Les crédits à moyen terme d’investissement
 Les crédits à moyen terme finançant les investissements dans le commerce de
distribution
 Les crédits à moyen terme finançant les constructions à usage industriel et
commercial
 Les crédits à moyen terme finançant les équipements professionnels
 Les crédits à moyen terme finançant la privatisation
Page 8
Chapitre I : Contexte Général

 Les crédits à moyen terme pour la production de plants


 Les crédits à moyen terme finançant la multiplication des semences de
pommes de terre
 Les crédits à moyen terme de réparation des équipements agricoles et de pêche
 Les crédits à moyen terme à la production
 Les crédits à moyen terme d’acquisition de matériel de transport
 Les crédits à moyen terme finançant les investissements dans l’artisanat, les
petites entreprises et petits métier.
 Les crédits à moyen terme de l’acquisition de matériel agricoles.
Les crédits à long terme :
Ces crédits d’une durée supérieure à 7ans et inférieure ou égale à 15ans. Ces crédits
sont destinés à financer les investissements dans les secteurs de l’agriculture et de la pêche, de
l’industrie, du tourisme et des autres services tel que fixés par le décret n°94/492 du 28 février
1994 dont la durée de vie excède 7ans de rentabilité nécessite un délai de remboursement
supérieure à 7ans et à établir l’équilibre de la structure financière des entreprises relevant de
ces mêmes secteur.
3.1.2. Bon du trésor
Les bons du trésor sont des titres émis par l’Etat à une échéance courte (13, 26 ou 52
semaine) ou à moyen termes en représentation d’emprunts dans le cadre de l’équilibre
budgétaire sont négociable auprès de l’ensemble des banques intervenant sur le Marché
Monétaire. Le montant unitaire de chaque bon est fixé à mille dinars « Art 1.ca banques n°91-
21 »
Il y a deux types de bons du trésor :
- Bons du trésor négociable
- Bons du trésor cessible
Les bons du trésor négociables sont des bons du trésor qui peuvent être vendus ou
achetés qu’en bourse
Les bons du trésor cessibles sont des bons du trésor qui peuvent être cédé directement
à la clientèle
La société Tunisienne Interprofessionnelle de Compensation des Valeurs Mobilières
(STICODEVAM) déclare a la banque centrale les lignes du trésor c’est-à-dire les bons du
trésor qui circulent actuellement sur le marché monétaire. Chaque ligne de bons du trésor
possède un code qui s’appelle ISIN et caractérisée par un libellé, une date d’échéance finale,
la catégorie (négociable/cessible) et un taux d’intérêt.
Page 9
Chapitre I : Contexte Général

Les banques d’autre part, déclarent les encours de lignes de bons du trésor c’est-à-dire
le nombre de bons du trésor qu’elles possèdent pour chaque ligne de bons du trésor.
3.1.3. Les contrôles à effectuer
Les contrôles spécifiques aux crédits admis au refinancement sont :
- Contrôle de l’éligibilité du crédit au refinancement de la BCT : quant à sa nature,
l’existence d’éventuelles réserves ou recommandation émises à son égard.
- Rapprochement des montants présentés avec les déclarations des engagements au
niveau de la centrale des risques
- Contrôle de la qualité de la créance : Vérification de la classification. Seules les
créances courantes sont admises en couverture du refinancement de la banque
centrale de Tunisie
3.2.Le système existant
L’application existante est opérationnelle sur le système HP/3000. Elle est développée
essentiellement en langage de programmation COBOL et les données sont structurées en
fichier classiques en BD IMAGE/3000
Actuellement les transactions informatisées au niveau du service de suivi des
contreparties de refinancement sont les suivantes :
Nom de la procédure Fonction
MFMAJ Saisie contrôlée des crédits

MFERB Saisie contrôlée des mises en remboursement des crédits

MFMPTF Ajout des crédits admis au portefeuille

MFFIN Historique et suppression des fichiers du journal

MFTMB Sélection et édition des tombées

Tableau 1 Tableau des procédures actuelles

4. Etude du sujet
4.1.Problématique
Comme il a été déjà été mentionné, la direction générale des systèmes d’information
rencontre des problèmes notamment au niveau des échanges de données entre le service du
marché monétaire et le service de contrôle de refinancement.
Les principales insuffisances et limites du système existant sont :

Page 10
Chapitre I : Contexte Général

 Manque de sécurité des données : le transfert manuel des dossiers entre le service du
marché monétaire et le service de contrôle de refinancement peut provoquer la perte des
données.
 Vérification des crédits à mettre en garantie par un contrôle visuel sur les fichiers
EXCEL envoyés par les banques.
 Vérification des bons du trésor à mettre en garantie par un visuel sur les fichiers
EXCEL envoyés par les banques.
 L’utilisateur ne bénéficie pas de tableaux de bord fiables et conviviaux dans le cadre du
suivi des portefeuilles des crédits des banques.

4.2.Etude des solutions possibles


Afin de répondre aux besoins et remédier aux problèmes décrits précédemment, nous
avons mis en place quelques solutions que nous décrivons ci-dessous:
 Automatisation des tâches effectuées manuellement.
 Etude plus détaillée des demandes d’emprunt.
 La migration vers une base de données ORACLE et la suppression des
fichiers classiques.
 Remettre en question la sécurité des données etc.
5. Besoins Fonctionnels et Besoins Non Fonctionnels
5.1.Besoins Fonctionnels
La détermination des besoins fonctionnels est une étape importante dans le
développement d’une application.
Nous présentons dans cette partie les différents besoins fonctionnels de notre sujet.
5.1.1. Besoins Fonctionnels de la partie utilisateur BCT
 Authentification : L’utilisation du moteur de sécurité de la banque centrale pour prendre
en charge l’authentification des utilisateurs.

 Consultation d’une opération de refinancement : L’application doit afficher les


informations relatives à un refinancement.

 Gestion du portefeuille des crédits


La gestion du portefeuille de crédits comporte :
- Saisie d'un crédit : L’application doit permettre à l’utilisateur de saisir les données relatives
à un crédit.

Page 11
Chapitre I : Contexte Général

- Consultation d'un crédit: L’application doit permettre à l’utilisateur de consulter les


données relatives à un crédit.
- Modification d'un crédit : L’application doit permettre à l’utilisateur de modifier les
données relatives à un crédit.
- Sélection des tombées: L’application doit permettre à l’utilisateur de supprimer les crédits
dont la date d'échéance est inférieure à la date du jour.
- Suppression d'un crédit: L’application doit permettre à l’utilisateur de supprimer un crédit.
 Gestion des encours des bons du trésor
La gestion des encours des bons du trésor comporte :
- Saisie d'un bon du trésor : Réception du bon du trésor de la part de STICODVAM.
- Consultation d'un bon du trésor : L’application doit permettre à l’utilisateur de consulter
les données relatives à un bon du trésor.
- Modification d'un bon du trésor: L'application doit permettre à l'utilisateur de modifier les
données relatives à un bon du trésor.
- Vérifier l'échéance d'un bon du trésor: L'application doit permettre à l'utilisateur de vérifier
si l'échéance d'un bon du trésor a été atteinte ou pas.
 Gestion Garantie des Crédits
La gestion de garantie de Crédits comporte :
- Saisie d'une garantie Crédit : L’application doit permettre à l’utilisateur de saisir les
données relatives à une garantie.
- Consultation d'une garantie Crédit: L’application doit permettre à l’utilisateur de consulter
les données relatives à une garantie.
- Modification d'une garantie Crédit: L’application doit permettre à l’utilisateur de modifier
les données relatives à une garantie.
- Arrivée à l’échéance de refinancement: L’application doit permettre à l’utilisateur de
supprimer les données relatives à une garantie.

 Gestion Garantie des Bons du trésor


La gestion de garantie des Bons du trésor comporte :
- Saisie d'une garantie Bon du trésor : L’application doit permettre à l’utilisateur de saisir les
données relatives à une garantie.
- Modification Garantie Bon du trésor : L’application doit permettre à l’utilisateur de
modifier les données relatives à une garantie.

Page 12
Chapitre I : Contexte Général

- Consultation Garantie Bon du trésor : L’application doit permettre à l’utilisateur de


consulter les données relatives à une garantie.
- Arrivée à l’échéance du bon du trésor: L’application doit permettre à l’utilisateur de
supprimer les données relatives à une garantie.
 Gestion du Référentiel Banques
La gestion du référentiel des banques comporte :
- Saisie d'une banque : L’application doit permettre à l’utilisateur de saisir les données
relatives à une banque.
- Consultation d'une banque: L’application doit permettre à l’utilisateur de consulter les
données relatives à une banque.
- Modification d'une banque: L’application doit permettre à l’utilisateur de modifier les
données relatives à une banque.
- Suppression d'une banque: L’application doit permettre à l’utilisateur de supprimer les
données relatives à une banque.
 Gestion du Référentiel Clients
La gestion du référentiel des clients comporte :
- Saisie d'un client : L’application doit permettre à l’utilisateur de saisir les données relatives
à un client.
- Consultation d'un client: L’application doit permettre à l’utilisateur de consulter les
données relatives à un client.
- Modification d'un client: L’application doit permettre à l’utilisateur de modifier les
données relatives à un client.
- Suppression d'un client: L’application doit permettre à l’utilisateur de supprimer les
données relatives à un client.
 Gestion du Référentiel Bon du trésor
La gestion du référentiel des bons du trésor comporte :
- Saisie d'un bon du trésor : L’application doit permettre à l’utilisateur de saisir les données
relatives à un bon du trésor.
- Consultation d'un bon du trésor: L’application doit permettre à l’utilisateur de consulter les
données relatives à un bon du trésor.
- Modification d'un bon du trésor: L’application doit permettre à l’utilisateur de modifier les
données relatives à un bon du trésor.
- Suppression d'un bon du trésor: L’application doit permettre à l’utilisateur de supprimer les
données relatives à un bon du trésor.
Page 13
Chapitre I : Contexte Général

 Gestion du Référentiel Crédit


La gestion du référentiel des crédits comporte :
- Saisie d'un crédit : L’application doit permettre à l’utilisateur de saisir les données relatives
à un crédit.
- Consultation d'un crédit: L’application doit permettre à l’utilisateur de consulter les
données relatives à un crédit.
- Modification d'un crédit: L’application doit permettre à l’utilisateur de modifier les
données relatives à un crédit.
- Suppression d'un crédit: L’application doit permettre à l’utilisateur de supprimer les
données relatives à un crédit.
5.1.2. Besoins Fonctionnels de la partie Administrateur
L'administrateur peut effectuer les mêmes tâches que n'importe quel utilisateur en plus
de la gestion des utilisateurs.
 Gestion des Utilisateurs
La gestion du référentiel des crédits comporte :
- Saisie d’un nouvel utilisateur : L’application doit permettre à l’administrateur d’ajouter de
nouveaux utilisateurs.
- Consultation d’un utilisateur : L’application doit permettre à l’administrateur de consulter un
utilisateur.
- Modification d’un utilisateur : L’application doit permettre à l’administrateur de modifier un
utilisateur.
- Suppression d’un utilisateur : L’application doit permettre à l’administrateur de supprimer un
utilisateur.
5.2. Besoins Non Fonctionnels
Les besoins non fonctionnels peuvent être représentés sous forme de besoins de
performances, matériaux, de sécurité et d’utilisation.
Une première analyse des conditions d'exploitation souhaitées, nous a permis
d’identifier les besoins non fonctionnels décrits ci-après :
 Architecture : Le système doit fonctionner en architecture 3-tiers.
 Sécurité : Le système doit garantir la fiabilité des données et des traitements.
 Ergonomie : Le système doit être facile à utiliser. En effet, les interfaces doivent être
conviviales c’est-à-dire ergonomique, simple et adaptées à l’utilisateur.

Page 14
Chapitre I : Contexte Général

 Outils de développement : Dans notre travail nous allons suivre le langage de


modélisation UML pour la conception, et pour le volet de réalisation nous allons utiliser
ORACLE 11 pour le SGBDR, Forms et Reports comme outils de développement et le
système d’exploitation Linux Redhat 5.5.
6. Environnement logiciel du travail
Les besoins étant établis, nous proposons de définir l’environnement logiciel de notre
application.
L’environnement de travail doit satisfaire à une configuration logicielle bien
déterminée. En effet, nous avons besoin des environnements suivants:
6.1.Logiciel de réalisation de conception
La partie conception est une partie primordiale dans la réalisation d’un projet. Pour ce
faire nous avons opté nous avons opté pour l’utilisation de l’approche proposée par Pascal
Roques [3], qui est une composition de la méthode agile et le processus unifié.
Les étapes nécessaires afin d’aboutir aux codes permettant la réalisation de notre
application sont décrits ci-dessous :
-Nous allons tout d’abord identifier les diagrammes de cas d’utilisation à partir des
besoins fonctionnels. Puis la description de scenario de chaque cas va nous permettre de
définir les diagrammes de séquences systèmes.
-En deuxième lieu, nous proposons de définir à partir des besoins fonctionnels les
maquettes de notre application. En se basant sur ces derniers, nous allons modéliser les
diagrammes de classe participantes qui sont composés de trois principales classes d’analyses :
les classes de dialogues, les classes de contrôle et les classes entités. La modélisation de ce
type de diagrammes est très importante car ils font la jonction entre les cas d’utilisation, les
maquettes et les autres diagrammes de conception. Puis en se basant sur les diagrammes de
séquences systèmes et les diagrammes de classes participantes nous proposons la
modélisation des diagrammes de séquences détaillés qui aident à écrire le code à l’intérieur
des opérations, ceci est un moyen utile à la définition des objets de chaque classe qui
communiquent en s’envoyant des messages.
-Finalement, en se basant sur les diagrammes de séquences détaillés et les diagrammes
de classes participantes nous proposons la modélisation du diagramme de classe global qui
illustre la structure du code par ses attributs, ses relations et ses méthodes.

Page 15
Chapitre I : Contexte Général

Diagramme Scénario
Diagramme Diagramme Diagramme Diagramme
Besoins de cas détaillé de
séquence de classe de séquence de classe
fonctionnels d'utilisation chaque cas
système participante détaillé global
initial d'utilisation

Figure 2 Schéma du processus de modélisation

6.2. Outil de modélisation Power AMC


POWER AMC est un outil de modélisation des données et des processus. Il a été créé
par la société Sybase, désormais propriété de SAP.
Présentation et concept de POWER AMC
POWER AMC est l’un des premiers outils qui permet d’élaborer des modèles de
données de manière graphique et de les implémenter quel que soit le SGBD et ce de manière
automatique. De même l’outil permet de modéliser les processus métiers.
Fonctionnalités principales de POWER AMC
 Modélisation des processus métiers
 Modélisation des données en MERISE MCD, MLD, MPD ou en UML
 Reverse Engineering des bases de données
 Estimation du poids de la base
 Générateur de documentations
Avantages de POWER AMC
 Power AMC est un outil simple à utiliser. Le déploiement d’un poste suffit à
rendre l’outil efficient.
 L’outil fonctionne nativement avec tous les SGBD courants du marché
(ORACLE, SQL SERVEUR, DB2/UDB)
 L’outil permet une documentation des développements
 L’outil permet une retro-documentation de l’existant

Page 16
Chapitre I : Contexte Général

Figure 3 Power AMC 15.1[4]

6.3.Architecture mise en place


L’architecture choisie pour notre application est l’architecture trois tiers. Il s'agit d'un
modèle logique d'architecture applicative qui vise à modéliser une application comme un
empilement de trois couches logicielles :
 la présentation des données : correspondant à l'affichage, la restitution sur le
poste de travail, le dialogue avec l'utilisateur ;
 le traitement métier des données : correspondant à la mise en œuvre de
l'ensemble des règles de gestion et de la logique applicative ;
 et enfin l'accès aux données persistantes : correspondant aux données qui sont
destinées à être conservées sur la durée, voire de manière définitive.
Objectifs d’une architecture 3 tiers :

Ce modèle d'architecture 3-tiers a pour objectif de répondre aux préoccupations suivantes :

 Allègement du poste de travail client (notamment vis-à-vis des architectures


classiques client-serveur de données – typiques des applications dans un
contexte Oracle/Unix) ;
 Prise en compte de l'hétérogénéité des plates-formes (serveurs, clients, langages, etc.) ;
 Introduction de clients dits « légers » (plus liée aux technologies Intranet/HTML qu'au 3-
tiers proprement dit) ;

Page 17
Chapitre I : Contexte Général

 Amélioration de la sécurité des données, en supprimant le lien entre le client et les


données. Le serveur a pour tâche, en plus des traitements purement métiers, de vérifier
l'intégrité et la validité des données avant de les envoyer dans la couche de données.
 Rupture du lien de propriété exclusive entre application et données. Dans ce modèle, la
base de données peut être plus facilement normalisée et intégrée à un entrepôt de données.
 Et enfin, meilleure répartition de la charge entre différents serveurs d'application. [5]

Figure 4 Architecture 3 tiers [6]

7. Conclusion
Nous avons présenté au niveau de ce chapitre notre organisme d'accueil, son rôle, son
pouvoir ainsi que la direction dans laquelle on a travaillé.
Nous avons également dégagé notre problématique et étudié scrupuleusement les
solutions possibles pour remédier à ces insuffisances.
Ce qui nous a amené à la proposition de notre solution et identifier par la suite les
besoins fonctionnels et non fonctionnels.

Page 18
Chapitre II : Spécification des Exigences

Chapitre II :
Spécification
Des
Exigences

Page 19
Chapitre II : Spécification des Exigences

1. Introduction
Le but principal de ce deuxième chapitre consiste à analyser les différents besoins
fonctionnels et non fonctionnels identifiés dans le chapitre précédent.
Nous débutons par présenter les différents acteurs du système. Ensuite, on entre dans
le vif du sujet en définissant les différents cas d’utilisation relatifs aux besoins. Et enfin, on
termine par établir un scenario correspondant à chaque cas d’utilisation afin d’élaborer les
diagrammes de séquences système.
C’est en se basant sur l'étude de l’existant qu’on pourra déceler le fond du problème et
trouver la solution adéquate pour y remédier.
Il convient donc d’y prêter une grande attention pour la rendre la plus claire et la
moins ambiguë possible, puisque tout ce qui suit dépendra de sa qualité.
2. Spécification générale des exigences
La spécification générale des exigences se fait à travers le diagramme de cas
d’utilisation inspiré des besoins identifiés dans le premier chapitre.
Pour établir ce diagramme, on doit tout d’abord identifier les acteurs du système et par
la suite les cas d’utilisation.
2.1.Identification des acteurs
Un acteur est une entité externe qui interagit avec le système (opérateur, centre distant,
autre système...). En réponse à l'action d'un acteur, le système fournit un service qui
correspond à son besoin. Les acteurs peuvent être classés (hiérarchie). [7]
Dans notre application on distingue deux intervenants qui interagissent avec
l’interface :
 L’utilisateur BCT : c’est celui qui se charge de la gestion des contreparties de
refinancement.
 Administrateur : Il peut effectuer les mêmes opérations que l’utilisateur BCT à une
différence près. En effet, il assure la gestion des utilisateurs aussi.
2.2.Identification des cas d’utilisation
Après avoir identifié les différents besoins de notre système, on procède à l’expression
des cas d’utilisation. Nous présentons dans la figure numéro 5, le diagramme de cas
d’utilisation initial permettant d’associer chaque cas d’utilisation à l’acteur qui lui correspond.

Page 20
Chapitre II : Spécification des Exigences

<<include>>
Gèrer portefeuille crédit

<< include>>
Gèrer encours bon du trésor

<<include>>
Gèrer référentiel clients s'authentifier

<<include>>
Gèrer référentiel crédits

<<Utilisateur BCT>> <<include>>

Gèrer référentiel banques

<<include>>
Gèrer garanties bons du trésor

<<include>>

Consulter opération refinancement


<<include>>
<<include>>

Gèrer garanties crédits


<< include>>

Gèrer Utilisateurs
<<include>>
<<Administrateur>>

Figure 5 Diagramme de cas d’utilisation initial

Page 21
Chapitre II : Spécification des Exigences

2.3.Affectation des priorités aux cas d’utilisation :


Dans ce paragraphe, nous avons désigné les principaux cas d’utilisation qui constituent
notre application et nous les avons représentés dans le tableau numéro 2 en tenant compte du
facteur "priorité fonctionnelle".
Cas d’utilisation Priorité Acteur
S’authentifier 1 Utilisateur BCT
Gérer portefeuille crédit 2 Utilisateur BCT
Gérer encours bon du trésor 2 Utilisateur BCT
Gérer garantie crédit 1 Utilisateur BCT
Gérer garantie bon du trésor 1 Utilisateur BCT
Gérer référentiel crédit 3 Utilisateur BCT
Gérer référentiel bon du trésor 3 Utilisateur BCT
Gérer utilisateurs 3 Administrateur
Consulter refinancement 1 Utilisateur BCT

Tableau 2 Affectation des priorités aux cas d’utilisation

2.4.Raffinement des Cas d’utilisation


2.4.1. Raffinement du Cas d’utilisation « S’authentifier »
Dans ce qui suit, nous présentons la première étape à effectuer avant d’accéder à
l’application. Il s’agit de l’authentification. L’utilisateur saisit son login ainsi que son mot de
passe et clique sur le bouton « connexion ». Si ces derniers sont corrects, un menu principal
lui est affiché, dans le cas contraire, la possibilité de ressaisir à nouveau lui est offerte.
Nous illustrons dans la figure 6 le raffinement de l’authentification

Page 22
Chapitre II : Spécification des Exigences

S'authentifier

<<Utilisateur BCT>>

Acteur_2

Figure 6 Raffinement du Cas d’utilisation « S’authentifier »

Scénario du raffinement du cas d’utilisation « S’authentifier »

Dans le Tableau 3 qui suit, nous allons décrire le scénario détaillé de l’authentification :

Cas d’utilisation S’authentifier


Acteur Utilisateur BCT

Pré condition Aucune

Post condition Connexion effectuée

Scénario -L’utilisateur introduit le login et le mot de passe pour s’identifier


principal -Le système consulte la table « Utilisateurs » pour récupérer le profil de
l’utilisateur
-L’utilisateur est connecté selon les privilèges qui lui sont associés

Exception l’utilisateur introduit le mot de passe ou le login erroné :


le système envoie un avertissement d’erreur
EXTENSION Possibilité de saisir à nouveau le login et le mot de passe

Tableau 3 Scénario de l’authentification

Page 23
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système de l’Authentification

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 7 :
Authentification

<<system>>
Refinancement

<<Utilisateur BCT>>

1:Saisir(login,mot_de_passe)

alt Erreur

2:Afficher("Veuillez réessayer à nouveau")

Succès
3:Afficher le menu principal()

Figure 7 Diagramme Séquence Système « S’authentifier »

2.4.2. Raffinement du cas d’utilisation Gestion du portefeuille de crédits


La gestion du portefeuille de crédits comporte 5 opérations : l’ajout d’un crédit, la
consultation d’un crédit, la modification d’un crédit, la suppression d’un crédit et la sélection
des tombées.
Le raffinement de ce cas d’utilisation est représenté dans la figure 8:

Gérer portefeuille crédit

<<Utilisateur BCT>>

Consulter crédit Ajouter crédit Selectionner les tombées

<<extend>> <<extend>>

Modifier crédit Supprimer crédit

Figure 8 Raffinement du Cas d’utilisation « Gérer portefeuille de crédits »


Page 24
Chapitre II : Spécification des Exigences

Scénario de l’Ajout d’un crédit au portefeuille


Dans le tableau 4 qui suit, nous allons décrire le scénario détaillé de l’ajout d’un crédit dans le
Portefeuille:
Cas d’utilisation Ajout d’un crédit au portefeuille
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout d’un crédit effectué
Scénario principal -L’utilisateur BCT introduit les informations d’un crédit.
-Il clique sur le bouton « Ajouter ».
-Le système enregistre le nouveau crédit dans la table
-Le système affiche un message « Ajout effectué avec succès »
Exception L’utilisateur BCT introduit une valeur erronée, laisse un champ vide ou le
crédit existe déjà dans la table « Portefeuille crédits ».
Le système affiche un message d’alerte.
Extension -

Tableau 4 Scénario Ajouter un crédit au portefeuille

Diagramme de Séquence Système de l’Ajout d’un crédit au portefeuille


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 9:
Ajouter crédit

<<System>>
Refinancement

<<Utilisateur BCT>>

1:saisir details crédit ( )

alt
valides
2:Afficher(Ajout accepté)

invalides

3:Afficher (erreur)

Figure 9 Diagramme Séquence système de l'ajout d'un crédit au portefeuille

Scénario de la consultation d’un crédit du portefeuille

Page 25
Chapitre II : Spécification des Exigences

Dans le tableau 5 qui suit, nous allons décrire le scénario détaillé de la consultation d’un
crédit dans le Portefeuille:
Cas Consulter un crédit du portefeuille
d’utilisation
Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario -L’utilisateur BCT saisit les critères de recherche d’un crédit
principal -Le système cherche dans la base de données
-Le système affiche tous les détails du crédit recherché
Exception -L’utilisateur BCT introduit une valeur erronée, laisse un champ vide ou un critère
introuvable.
-Le système cherche dans la base de données
-Le système affiche un message d’erreur.
Extension -Modifier un crédit
-Supprimer un crédit

Tableau 5 Scénario de la Consultation d'un crédit du portefeuille

Diagramme de Séquence Système de la Consultation d’un crédit du portefeuille


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée
dans la figure 10 :

Page 26
Chapitre II : Spécification des Exigences
consulter portefeuille crédit

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (critères crédit)

alt critères valides

alt crédit existant

2:Afficher_details crédit ( )

crédit inexistant
3:Afficher (crédit inexistant)

critères invalides
4:Afficher (erreur)

Figure 10 Diagramme séquence système de la consultation d'un crédit du portefeuille

Scénario de la modification d’un crédit du portefeuille


Dans le tableau 6 qui suit, nous allons décrire le scénario détaillé de la modification d’un
crédit du Portefeuille:
Cas d’utilisation Modifier un crédit du portefeuille
Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Table « Portefeuille crédit » consultée.
Post condition Modification effectuée
Scénario principal -L’utilisateur BCT saisit les modifications à effectuer
-L’utilisateur BCT clique sur le bouton « Modifier »
-Le système met à jour la table et affiche un message de succès
Exception L’utilisateur BCT introduit une valeur erronée et clique sur le bouton
« Modifier »
Le système affiche un message d’erreur
Extension -

Tableau 6 Scénario de la modification d'un crédit du portefeuille

Page 27
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système de la modification d’un crédit du Portefeuille


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 11:
sequence modifier portefeuille crédit

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (modifications)

alt succès

2:Afficher (modification effectuée )

erreur
3:Afficher (erreur )

Figure 11 Diagramme Séquence système de la modification d'un crédit du portefeuille

Scénario de la sélection des tombées


Dans le tableau 7 qui suit, nous allons décrire le scénario détaillé de la sélection des tombées :
Cas Sélectionner des tombées
d’utilisation
Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Table « Portefeuille crédit » consultée
Post condition Suppression du crédit effectuée
Scénario -L’utilisateur BCT saisit une date.
principal -L’utilisateur BCT clique sur le bouton « Supprimer »
-Le système supprime les crédits de la base de données ayant la date d’échéance de
crédit inférieur à la date introduite.
Exception L’utilisateur BCT saisit une date invalide
L’utilisateur BCT clique sur le bouton « Supprimer»
le système affiche un message d’erreur
Extension -

Tableau 7 Scénario de la sélection des tombées

Page 28
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système de la sélection des tombées


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 12:
selection des tombées

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (date système)

alt date crédit <date systeme

2:Afficher (suppression effectuée)

date crédit > date systeme

3:Afficher (aucun crédit à supprimer)

Figure 12 Diagramme séquence système de la sélection des tombées

Scénario de la suppression d’un crédit du portefeuille


Dans le tableau 8 qui suit, nous allons décrire le scénario détaillé de la suppression d’un crédit
du portefeuille :
Cas d’utilisation Supprimer un crédit du portefeuille
Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Table « Portefeuille crédit » consultée
Post condition Suppression du crédit effectuée
Scénario principal L’utilisateur BCT saisit les critères de recherche d’un crédit
L’utilisateur BCT clique sur le bouton « Supprimer »
Le système supprime le crédit de la table et affiche un message
Exception L’utilisateur BCT saisit une valeur erronée ou laisse un champ vide.
L’utilisateur BCT clique sur le bouton « Supprimer»
Le système affiche un message d’erreur
Extension -

Tableau 8 Scénario de suppression d'un crédit

Page 29
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système de la suppression d’un crédit du portefeuille


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 13 :
Sequence supprimer crédit

<<System>>
Refinancement

<<Utilisateur BCT>>

1:click_bt supprimer crédit()

alt succès

2:Afficher(suppression effectuée)

erreur

3:Afficher (erreur)

Figure 13 Diagramme séquence système de la suppression d'un crédit du portefeuille

2.4.3. Raffinement du cas d’utilisation Gestion encours bon trésor


La gestion encours bon trésor comporte 5 opérations : l’ajout d’un bon trésor, la
consultation d’un bon trésor, la modification d’un bon trésor, la suppression d’un bon trésor et
vérification d’échéance d’un bon trésor
Le raffinement de ce cas d’utilisation est représenté dans la figure 14:

Page 30
Chapitre II : Spécification des Exigences

Gérer encours bons du trésor

<<Utilisateur BCT>>

Consulter bon du trésor Ajouter bon du trésor Verifier échéance bon du trésor

<<extend>> <<extend>>

Modifier bon du Supprimer bon du


trésor trésor

Figure 14 Raffinement du cas d'utilisation "Gérer encours bon du trésor"

Scénario de l’Ajout d’un bon du trésor à l’encours bon du trésor


Dans le tableau 9 qui suit, nous allons décrire le scénario détaillé de l’ajout d’un bon du trésor

Cas Ajouter un bon du trésor au portefeuille


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition L’apport d’un bon du trésor effectué
Scénario -L’utilisateur BCT saisit le bon du trésor envoyé par STICODVAM
principal -L’utilisateur BCT clique sur le bouton « Ajouter »
-le système enregistre le nouveau bon dans la table « Encours bon du trésor »
Exception -L’utilisateur BCT saisit des détails d’un bon du trésor qui existe déjà dans la base
de données, ne renseigne pas un champ obligatoire ou introduit un type de donnée
invalide
-L’utilisateur BCT clique sur le bouton « ajouter »
Le système affiche un message d’erreur
Extension -

Tableau 9 Scénario de l'ajout d'un bon du trésor

Page 31
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système de l’ajout d’un bon du trésor à l’encours


bon du trésor
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure15:
Ajouter bon trésor

<<System>>
Refinancement

<<Utilisateur BCT>>

1:saisir (details bon trésor)

alt
valides
2:Afficher (ajout accepté)

invalides

3:Afficher (erreur)

Figure 15 Diagramme séquence système de l'ajout d'un bon du trésor

Scénario de la consultation d’un bon du trésor


Dans le tableau 10 qui suit, nous allons décrire le scénario détaillé de la consultation d’un bon
du trésor

Page 32
Chapitre II : Spécification des Exigences

Cas Consulter encours bon du trésor


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario -L’utilisateur BCT saisit les critères de recherche du bon du trésor à consulter
principal -Le système cherche dans la base de données
-Le système affiche les informations concernant le bon du trésor
Exception L’utilisateur BCT saisit un critère de recherche introuvable, laisse un champ
obligatoire vide ou introduit une valeur erronée.
le système cherche dans la base de données
le système affiche un message d’erreur
Extension -

Tableau 10 Scénario de la consultation d'un bon du trésor

Diagramme de Séquence Système de la consultation d’un encours bon du


trésor
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 16:

Page 33
Chapitre II : Spécification des Exigences
consulter encours bon trésor

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (critères bon trésor )

alt critères valides

alt bon trésor existant

2:Afficher_details bon trésor ( )

bon trésor inexistant


3: Afficher (bon trésor inexistant)

critères invalides
4:Afficher (erreur)

Figure 16 Diagramme séquence système de la consultation d'un bon du


trésor

Scénario de la suppression d’un bon du trésor


Dans le tableau 11 qui suit, nous allons décrire le scénario détaillé de la suppression d’un bon
du trésor

Page 34
Chapitre II : Spécification des Exigences

Cas d’utilisation Suppression bon trésor


Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Table « encours bon trésor » consultée
Post condition Mise à jour effectuée
Scénario principal -L’utilisateur BCT saisit les critères du bon du trésor
-L’utilisateur BCT clique sur le bouton « supprimer »
-Le système supprime le bon du trésor de la base de données
-Le système affiche un message « suppression effectuée »
Extension -

Tableau 11 Scénario de suppression d'un bon du trésor

Diagramme de Séquence Système de la suppression d’un encours bon du


trésor
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 17 :
Sequence supprimer encours bon trésor

<<System>>
Refinancement

<<Utilisateur BCT>>

1:click_bt supprimer bon trésor()

alt succès

2:Afficher (suppression effectuée)

erreur

3:Afficher (erreur)

Figure 17 Diagramme séquence système de suppression d'un bon du trésor

Page 35
Chapitre II : Spécification des Exigences

Scénario du raffinement du cas d’utilisation modifier encours bon trésor

Dans le tableau 12 qui suit, nous allons décrire le scénario détaillé de la modification d’un bon
du trésor

Cas d’utilisation modifier encours bon du trésor


Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé.
Table « encours bon du trésor » consultée.
Post condition Modification effectuée
Scénario principal -L’utilisateur BCT saisit les modifications
-Le système met à jour la base de données
-Le système affiche un message de succès
Exception L’utilisateur BCT saisit un type de données invalide
Extension -

Tableau 12 Scénario de modification d'un bon du trésor

Diagramme de Séquence Système de modification d’un bon du trésor


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 18 :
modifier encours bon trésor

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (modifications)

alt succès

2:Afficher (modification effectuée)

erreur
3:Afficher (erreur)

Figure 18 Diagramme séquence système de modification d'un bon du trésor

Page 36
Chapitre II : Spécification des Exigences

Scénario du raffinement du cas d’utilisation vérifier échéance bon du trésor


Dans le tableau 13 qui suit, nous allons décrire le scénario détaillé de la vérification de
l’échéance d’un bon du trésor

Cas Vérifier échéance bon du trésor


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Table « Encours bon du trésor » consultée
Post condition Vérification effectuée
Scénario -L’utilisateur BCT saisit une date
principal -Le système consulte la base de données
-Le système affiche un message qui indique si le bon du trésor a atteint la date
d’échéance ou pas.
Exception L’utilisateur BCT saisit une date invalide
Extension -

Tableau 13 Scénario de vérification de l'échéance d'un bon du trésor

Diagramme de Séquence Système de la vérification échéance bon du trésor

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 19 :

Page 37
Chapitre II : Spécification des Exigences
verification echeance bon trésor

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (date règlement operation)

alt date crédit <date systeme

2:Afficher (date échéance atteinte)

date crédit > date systeme


3:Afficher ( date échéance n'est pas
encore atteinte)

Figure 19 Diagramme séquence système de vérification de l'échéance d'un bon du


trésor

2.4.4. Raffinement du cas d’utilisation Gestion garantie crédit


La gestion des garanties crédit comporte 6 opérations : l’ajout d’une garantie crédit, la
consultation d’une garantie crédit, la modification d’une garantie crédit, la suppression d’une
garantie crédit et la consultation d’une opération de refinancement
Le raffinement de ce cas d’utilisation est représenté dans la figure 20:

Page 38
Chapitre II : Spécification des Exigences

Gérer garantie crédits

<<Utilisateur BCT>>

Consulter garantie crédits Consulter operation de


Ajouter garantie crédits
refinancement

<<extend>> <<extend>>

Modifier garantie crédits Supprimer garantie crédits

Figure 20 Raffinement du cas d'utilisation "Gérer garantie crédit"

Description textuelle du sous cas « Ajouter garantie crédit »


Dans le tableau 14 qui suit, nous allons décrire le scénario détaillé de la consultation d’une
garantie crédit :

Page 39
Chapitre II : Spécification des Exigences

Cas Ajouter garantie crédit


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout effectué
Scénario -L’utilisateur BCT saisit la date de l’opération de refinancement à consulter.
principal -Le système cherche dans la base de données
-Le système affiche les informations concernant l’opération de refinancement
relative à la date saisie.
-Une liste de crédits pouvant être pris en garanties est chargée.
-L’utilisateur BCT sélectionne les crédits qu’il veut prendre en garanties à
l’opération de refinancement.
-Il clique sur le bouton « Enregistrer »
-Le système enregistre le crédit dans la table « garantie de crédit »
-Le système met à jour la date mise en garantie dans la table « Portefeuille crédits »
Exception L’utilisateur BCT saisit une date d’une opération introuvable ou introduit un type
de donnée invalide
Le système affiche un message d’erreur
-L’utilisateur BCT ne sélectionne aucun crédit
Le système n’affiche « aucun crédit sélectionné »
Extension -

Tableau 14 Scénario ajouter garantie crédit

Diagramme de Séquence Système de l’Ajout garantie crédit


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 21:

Page 40
Chapitre II : Spécification des Exigences
Ajouter garantie crédit

<<system>>
Refinancement

<<Utilisateur BCT>>

1:Saisir(date opération)

alt Valide
2:Afficher(opération de refinancement)

3:Sélectionner(crédit)

4:Afficher(Ajout effectué)

Invalide
5:Afficher(erreur)

Figure 21 Diagramme séquence système de l'ajout d'une garantie crédit

Description textuelle du sous cas « Modifier garantie crédit »


Dans le tableau 15 qui suit, nous allons décrire le scénario détaillé de la modification d’un bon
du trésor

Cas d’utilisation Modifier garantie crédit


Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Table « garantie crédit » consultée
Post condition Modification effectuée
Scénario principal -L’utilisateur BCT modifie une garantie crédit
-L’utilisateur BCT clique sur le bouton « Modifier »
-Le système met à jour les tables de données
-Le système affiche un message « Modification effectuée »
Exception -L’utilisateur BCT introduit un type de données invalide
L’utilisateur BCT clique sur le bouton « Modifier »
Le système affiche un message d’erreur
Extension -

Tableau 15 Scénario de modification d'une garantie crédit

Page 41
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système de la modification garantie crédit


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans
la figure 22 :
Modifier garantie crédit

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (modifications)

alt succès

2:Afficher(modification effectuée)

erreur
3:Afficher (erreur )

Figure 22 Diagramme séquence système de modification d'une garantie crédit

Description textuelle du sous cas « Consulter garantie crédit »


Dans le tableau 16 qui suit, nous allons décrire le scénario détaillé de la consultation d’un bon
du trésor

Cas Consulter garantie crédit


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario -L’utilisateur BCT introduit les critères de recherche de garantie crédit à consulter
principal -Le système cherche dans la base de données
-Le système affiche toutes les informations relatives aux critères saisis
Exception L’utilisateur BCT saisit des critères ne correspondant à aucun enregistrement ou la
table à consulter est vide
Le système affiche un message d’erreur
Extension -Modifier garanties crédits
-Supprimer garanties crédits

Page 42
Chapitre II : Spécification des Exigences

Tableau 16 Scénario de consultation d'une garantie crédit

Diagramme de Séquence Système de la consultation garantie crédit

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 23:
consulter garantie crédit

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (critères garantie crédit )

alt critères valides

alt garantie crédit existante

2:Afficher_details garantie crédit ( )

garantie crédit inexistante


3:Afficher( Garantie crédit inexistante)

critères invalides
4:Afficher (erreur)

Figure 23 Diagramme séquence système de consultation d'une garantie crédit

Description textuelle du sous cas « Supprimer garantie crédit »


Dans le tableau 17 qui suit, nous allons décrire le scénario détaillé de la suppression d’un bon
du trésor

Page 43
Chapitre II : Spécification des Exigences

Cas Supprimer garantie crédit


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Table « garanties crédits » consultée
Post condition Consultation effectuée
Scénario -L’utilisateur BCT clique sur le bouton « Supprimer »
principal -Le système supprime la base de données
-Le système affiche un message d’erreur ou de succès
Exception L’utilisateur BCT saisit des critères ne correspondant à aucun enregistrement ou la
table à consulter est vide
Extension -

Tableau 17 Scénario de suppression d'une garantie crédit

Diagramme de Séquence Système de la suppression d’un garantie crédit


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 24 :
Sequence supprimer garantie crédit

<<System>>
Refinancement

<<Utilisateur BCT>>

1:click_bt supprimer garantie crédit ( )

alt succès

2:Afficher (suppression effectuée)

erreur

3:Afficher (erreur)

Figure 24 Diagramme séquence système de suppression d'une garantie crédit

Page 44
Chapitre II : Spécification des Exigences

Description textuelle du sous cas « consulter opération de refinancement »


Dans le tableau 18 qui suit, nous allons décrire le scénario détaillé de consultation d’une
opération de refinancement :

Cas Consulter opération de refinancement


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario L’utilisateur BCT introduit les critères de recherche de l’opération de
principal refinancement
Le système consulte la base de données
Le système affiche les détails de l’opération
Exception L’utilisateur BCT saisit des critères ne correspondant à aucun enregistrement ou la
table à consulter est vide
Extension -

Tableau 18 Scénario de consultation d'une opération de refinancement

Diagramme de Séquence Système de la consultation de l’opération de


refinancement

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 25 :

Page 45
Chapitre II : Spécification des Exigences
Consulter operation refinancement

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir ( critères operation )

alt critères valides

alt operation existante


2:Afficher _details operation de
refinancement ( )

operation inexistante
3:Afficher(operation de refinancement
inexistante)

critères invalides
4:Afficher (erreur)

Figure 25 Diagramme séquence système de consultation d'une opération de


refinancement

2.4.5. Raffinement du cas d’utilisation Gestion garantie bon trésor


La gestion des garanties bon du trésor comporte 6 opérations : l’ajout d’une garantie bon
du trésor, la consultation d’une garantie bon du trésor, la modification d’une garantie bon
du trésor, la suppression d’une garantie bon du trésor et la consultation d’une opération de
refinancement
Le raffinement de ce cas d’utilisation est représenté dans la figure 26:

Page 46
Chapitre II : Spécification des Exigences

Gérer garantie bons du trésor

<<Utilisateur BCT>>

Consulter operation de
Consulter garantie bons du trésor Ajouter garantie bons du trésor refinancement

<<extend>> <<extend>>

Supprimer garantie bons du trésor


Modifier garantie bons du trésor

Figure 26 Raffinement du cas "Gestion garanties bon du trésor"

Description textuelle du sous cas « Ajouter garantie bon trésor »


Dans le tableau 19 qui suit, nous allons décrire le scénario détaillé de l’ajout d’une garantie
bon du trésor :

Page 47
Chapitre II : Spécification des Exigences

Cas Ajouter garantie bon trésor


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout effectué
Scénario -L’utilisateur BCT saisit la date de l’opération de refinancement à consulter.
principal -Le système cherche dans la base de données
-Le système affiche les informations concernant l’opération de refinancement
relative à la date saisie.
-Une liste de bons du trésor pouvant être pris en garanties est chargée.
-L’utilisateur BCT sélectionne les bons du trésor qu’il veut prendre en garanties à
l’opération de refinancement.
-Il clique sur le bouton « Enregistrer »
-Le système enregistre le bon du trésor dans la table « garantie bon du trésor »
-Le système met à jour la date mise en garantie dans la table « Encours bon du
trésor »
Exception -L’utilisateur BCT saisit des critères qui n’existent pas ou introduit un type de
donnée invalide
Le système affiche un message d’erreur
-L’utilisateur BCT ne sélectionne aucun bon du trésor
Le système affiche « aucun bon du trésor sélectionné »

Extension -

Tableau 19 Scénario de l'ajout d'un bon du trésor

Diagramme de Séquence Système de l’Ajout garantie bon du trésor


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans
la figure 27 :

Page 48
Chapitre II : Spécification des Exigences
Ajouter garantie bon du trésor

<<system>>
Refinancement

<<Utilisateur BCT>>

1:Saisir(date opération)

alt Valide
2:Afficher(opération de refinancement)

3:Sélectionner(bon du trésor)

4:Afficher(Ajout effectué)

Invalide
5:Afficher(erreur)

Figure 27 Diagramme séquence système de l'ajout d'une garantie bon du trésor

Description textuelle du sous cas « Modifier garantie bon du trésor »


Dans le tableau 20 qui suit, nous allons décrire le scénario détaillé de la modification d’une
garantie bon du trésor :

Cas d’utilisation Modifier garantie bon du trésor


Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Table « garantie bon du trésor» consultée
Post condition Modification effectuée
Scénario principal -L’utilisateur BCT modifie une garantie bon du trésor
-Le système met à jour les tables des données
-Le système affiche un message « Modification effectuée »
Exception -L’utilisateur BCT saisit un type de données invalide
Le système affiche un message d’erreur
Extension -

Tableau 20 Scénario de modification d'une garantie bon du trésor

Page 49
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système de la modification garantie bon du trésor


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 28:
Sequence modifier garantie bon trésor

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (modifications)

alt succès

2:Afficher (modification effectuée)

erreur
3:Afficher (erreur)

Figure 28 Diagramme séquence système modification d'une garantie bon du


trésor

Description textuelle du sous cas « Consulter garantie bon du trésor »


Dans le tableau 21 qui suit, nous allons décrire le scénario détaillé de consultation d’une
garantie bon du trésor :

Page 50
Chapitre II : Spécification des Exigences

Cas Consulter garantie bon du trésor


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario -L’utilisateur BCT introduit les critères de recherche d’une garantie bon du trésor.
principal -Le système cherche dans la base de données
-Le système affiche toutes les informations relatives aux critères saisis
Exception L’utilisateur BCT saisit des critères ne correspondant à aucun enregistrement ou la
table à consulter est vide
Le système affiche un message d’erreur
Extension -Modifier garanties crédits
-Supprimer garantie des crédits

Tableau 21 Scénario de consultation d'une garantie bon du trésor

Diagramme de Séquence Système de la consultation garantie bon du trésor

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 29:

Page 51
Chapitre II : Spécification des Exigences
sequence consulter garantie bon trésor

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (critères garantie bon trésor )

alt critères valides

alt garantie bon trésor existante

2:Afficher details garantie bon trésor ( )

garantie bon trésor inexistante


3: Afficher (Garantie bon trésort
inexistante )

critères invalides
4:Afficher (erreur )

Figure 29 Diagramme séquence sytème consulter garantie bon du trésor

Description textuelle du sous cas « Supprimer garantie bon du trésor


Dans le tableau 22 qui suit, nous allons décrire le scénario détaillé de suppression d’une
garantie bon du trésor :

Cas d’utilisation Supprimer garantie bon du trésor


Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario principal -L’utilisateur BCT clique sur le bouton « Supprimer »
-Le système affiche un message de succès
Exception -Le système commet une erreur

Tableau 22 Scénario de suppression d'une garantie bon du trésor

Page 52
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système de la suppression d’un garantie bon du


trésor
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 30:
Sequence supprimer garantie bon trésor

<<System>>
Refinancement

<<Utilisateur BCT>>

1:click_bt supprimer garantie bon trésor()

alt succès

2:Afficher(suppression effectuée)

erreur

3:Afficher (erreur)

Figure 30 Diagramme séquence système Supprimer garantie bon du trésor

Description textuelle du sous cas « consulter opération de refinancement »


Dans le tableau 23 qui suit, nous allons décrire le scénario détaillé de consultation d’une
opération de refinancement :

Page 53
Chapitre II : Spécification des Exigences

Cas Consulter opération de refinancement


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario -L’utilisateur BCT introduit les critères de recherche de l’opération de
principal refinancement
-Le système consulte la base de données
-Le système affiche les détails de l’opération
Exception -L’utilisateur BCT saisit des critères ne correspondant à aucun enregistrement ou la
table à consulter est vide
Extension -

Tableau 23 Scénario Consulter opération refinancement

Diagramme Séquence Système de la consultation de l’opération de refinancement

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 31:

Page 54
Chapitre II : Spécification des Exigences
Consulter operation refinancement

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir ( critères operation )

alt critères valides

alt operation existante


2:Afficher _details operation de
refinancement ( )

operation inexistante
3:Afficher(operation de refinancement
inexistante)

critères invalides
4:Afficher (erreur)

Figure 31 Diagramme séquence système consulter opération de refinancement

2.4.6. Raffinement du cas d’utilisation Gestion référentiel crédit


La gestion du référentiel crédit comporte 3 opérations : l’ajout d’un crédit, la consultation
d’un crédit, la modification d’un crédit
Le raffinement de ce cas d’utilisation est représenté dans la figure 32:

Page 55
Chapitre II : Spécification des Exigences

Gèrer Référentiel Crédits


<<Utiisateur BCT>>

Consulter Crédit Ajouter crédit

<<extend>>

Modifier crédit

Figure 32 Raffinement du cas "Gestion référentiel crédit"

Description textuelle du sous cas « Ajouter référentiel crédit »


Dans le tableau 24 qui suit, nous allons décrire le scénario détaillé de l’ajout d’un crédit au
référentiel :

Cas d’utilisation Ajouter référentiel crédit


Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout du référentiel effectué
Scénario principal -L’utilisateur BCT saisit les informations
-L’utilisateur BCT clique sur le bouton « Ajouter »
-Le système enregistre le nouveau référentiel et affiche « Ajout effectué »
Exception Le système affiche un message d’erreur
Extension -

Tableau 24 Scénario de l'ajout d'un crédit au référentiel

Diagramme Séquence Système de l’ajout référentiel crédit

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans
la figure 33:

Page 56
Chapitre II : Spécification des Exigences
Sequence ajouter référentiel crédit

<<System>>
Refinancement

<<Utilisateur BCT>>

1:saisir (details référentiel crédit)

alt
valides
2:Afficher (ajout accepté)

invalides

3:Afficher(ajout non effectué)

Figure 33 Diagramme séquence système ajouter crédit au référentiel

Description textuelle du sous cas « Consulter référentiel crédit »


Dans le tableau 25 qui suit, nous allons décrire le scénario détaillé de consultation d’un crédit
du référentiel :

Cas d’utilisation Consulter référentiel crédit


Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario -L’utilisateur BCT saisit le code du crédit à consulter
principal -Le système cherche dans la base de données
-Le système affiche les informations relatives au code introduit
Exception -L’utilisateur BCT introduit un code qui n’existe pas ou un type de données
erroné.
-Le système cherche dans la base de données
Le système affiche « référentiel introuvable »
Extension -Modifier référentiel crédit
-Supprimer référentiel crédit
Tableau 25 Scénario de consultation d'un crédit du référentiel

Page 57
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système de la consultation référentiel crédit

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 34:
Sequence consulter référentiel crédit

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (critères référentiel crédit )

alt critères valides

alt référentiel crédit existant

2:Afficher_details référentiel crédit()

référentiel crédit inexistant


3:Afficher( Référentiel crédit inexistant )

critères invalides
4:Afficher (erreur )

Figure 34 Diagramme séquence système consulter crédit

Description textuelle du sous cas « Modifier référentiel crédit »


Dans le tableau 26 qui suit, nous allons décrire le scénario détaillé de modification d’un crédit
du référentiel :

Page 58
Chapitre II : Spécification des Exigences

Cas d’utilisation Modifier référentiel crédit


Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Table « référentiel crédit » consultée
Post condition Modification effectuée
Scénario principal -L’utilisateur BCT saisit les modifications
-L’utilisateur BCT clique sur le bouton « Modifier »
-Le système met à jour la table « référentiel crédit » et affiche un message
Exception -L’utilisateur BCT introduit un type de donnée invalide
Le système affiche un message d’erreur
Extension -

Tableau 26 Scénario de modification d'un crédit

Diagramme de Séquence Système de la modification référentiel crédit


Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 35:
sequence modifier référentiel crédit

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (modifications)

alt succès

2:Afficher (Modification effectuée)

erreur
3:Afficher (erreur)

Figure 35 Diagramme séquence système modifier crédit du référentiel

2.4.7. Raffinement du cas d’utilisation Gestion référentiel bon du trésor


La gestion du référentiel bon du trésor comporte 3 opérations : l’ajout d’un bon du trésor, la
consultation d’un bon du trésor, la modification d’un bon du trésor.
Le raffinement de ce cas d’utilisation est représenté dans la figure 36:

Page 59
Chapitre II : Spécification des Exigences

Gèrer Référentiel Bon du trésor

<<Utilisateur BCT>>

Consulter bon du trésor Ajouter bon du trésor

<<extend>>

Modifier Bon du trésor

Figure 36 Raffinement du sous cas "Gestion référentiel bon du trésor"

Description textuelle du sous cas « Ajouter référentiel bon du trésor »


Dans le tableau 27 qui suit, nous allons décrire le scénario détaillé de l’ajout d’un bon du
trésor au référentiel :

Cas Ajouter référentiel bon du trésor


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout du bon du trésor effectué
Scénario -L’utilisateur BCT saisit les informations
principal -L’utilisateur BCT clique sur le bouton « Ajouter »
-Le système enregistre le nouveau bon du trésor et affiche « Ajout effectué »
Exception L’utilisateur BCT ne renseigne pas les champs obligatoires, introduit un code qui
existe déjà ou saisit un type de donnée invalide
Le système affiche « Ajout non effectué »
Extension -

Tableau 27 Scénario de l'ajout d'un bon du trésor

Page 60
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système ajouter référentiel bon du trésor

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 37:
Sequence ajouter référentiel bon trésor

<<System>>
Refinancement

<<Utilisateur BCT>>

1:saisir (details référentiel bon trésor )

alt
valides
2:Afficher (ajout accepté )

invalides

3:Afficher(erreur)

Figure 37 Diagramme séquence système ajouter bon du trésor au référentiel

Description textuelle du sous cas « Consulter référentiel bon du trésor »


Dans le tableau 28 qui suit, nous allons décrire le scénario détaillé de consultation d’un bon
du trésor du référentiel :

Cas d’utilisation Consulter référentiel bon du trésor


Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario principal -L’utilisateur BCT saisit le code du bon du trésor à consulter
-Le système cherche dans la base de données
-Le système affiche les informations relatives au code introduit
Exception -L’utilisateur BCT introduit un code qui n’existe pas ou un type de données
erroné
Le système cherche dans la base de données
Le système affiche « bon du trésor introuvable »

Tableau 28 Scénario de consultation d'un bon du trésor du référentiel

Page 61
Chapitre II : Spécification des Exigences

²Diagramme de Séquence Système consulter référentiel bon trésor

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 38:
Sequence consulter référentiel bon trésor

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (critères référentiel bon trésor )

alt critères valides

alt référentiel bon trésor existant


2:Afficher_ details référentiel bon trésor
()

référentiel bon trésor inexistant


3: Afficher (référentiel bon trésort
inexistant )

critères invalides
4:Afficher (erreur )

Figure 38 Diagramme séquence système consulter un bon du trésor du


référentiel

Description textuelle du sous cas « Modifier référentiel bon du trésor »


Dans le tableau 29 qui suit, nous allons décrire le scénario détaillé de modification d’un bon
du trésor du référentiel :

Page 62
Chapitre II : Spécification des Exigences

Cas d’utilisation Modifier référentiel bon du trésor


Acteur Utilisateur BCT
Pré condition -L’utilisateur BCT identifié et autorisé
-Table « référentiel bon du trésor » consultée
Post condition Modification effectuée
Scénario principal -L’utilisateur BCT introduit les modifications
-L’utilisateur BCT clique sur le bouton « Modifier »
-Le système met à jour la table « référentiel bon du trésor »
Exception -L’utilisateur BCT introduit un type de donnée invalide
Le système affiche un message d’erreur
Extension -

Tableau 29 Scénario de modification d'un bon du trésor du référentiel

Diagramme de Séquence modifier référentiel bon du trésor

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 39:
Sequence modifier référentiel bon trésor

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (modifications)

alt succès

2:Afficher (modification effectuée)

erreur
3:Afficher (erreur )

Figure 39 Diagramme séquence système modifier bon du trésor du référentiel

2.4.8. Raffinement du cas d’utilisation Gestion référentiel client


La gestion des clients comporte 3 opérations : l’ajout d’un client, la consultation d’un client,
la modification d’un client.
Le raffinement de ce cas d’utilisation est représenté dans la figure 40:

Page 63
Chapitre II : Spécification des Exigences

Gèrer Référentiel Clients


<<Utiisateur BCT>>

Consulter Client Ajouter client

<<extend>>

Modifier client

Figure 40 Raffinement du cas "Gestion référentiel client"

Description textuelle du sous cas « Ajouter référentiel client »


Dans le tableau 30 qui suit, nous allons décrire le scénario détaillé de l’ajout d’un client au
référentiel :

Cas Ajouter référentiel client


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout de référentiel effectué
Scénario -L’utilisateur BCT saisit les informations
principal -L’utilisateur BCT clique sur le bouton « Ajouter »
-Le système enregistre le nouveau référentiel et affiche « Ajout effectué »
Exception -L’utilisateur BCT ne renseigne pas les champs obligatoires, introduit un code qui
existe déjà ou saisit un type de donnée invalide
Le système affiche un message d’erreur
« Ajout non effectué »
Extension -

Tableau 30 Scénario de l'ajout d'un client au référentiel

Page 64
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système ajouter référentiel client

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 41:
Sequence ajouter référentiel client

<<System>>
Refinancement

<<Utilisateur BCT>>

1:saisir (details référentiel client)

alt
valides
2:Afficher (ajout accepté )

invalides

3:Afficher(erreur )

Figure 41 Diagramme séquence système ajouter client au référentiel

Description textuelle du sous cas « Consulter référentiel client »


Dans le tableau 31 qui suit, nous allons décrire le scénario détaillé de consultation d’un client
du référentiel :

Cas d’utilisation Consulter référentiel clients


Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario principal -L’utilisateur BCT saisit le code du client à consulter
-Le système cherche dans la base de données
-Le système affiche les informations relatives au code introduit
Exception -L’utilisateur BCT introduit un code qui n’existe pas ou une valeur erronée
-Le système cherche dans la base de données
Le système affiche « client introuvable »

Tableau 31 Scénario Consulter client

Diagramme de Séquence Système consulter référentiel client

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 42:

Page 65
Chapitre II : Spécification des Exigences
Sequence consulter référentiel client

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (critères référentiel client)

alt critères valides

alt référentiel client existant

2:Afficher_details référentiel client()

référentiel client inexistant


3: Afficher (référentiel client
inexistant )

critères invalides
4:Afficher (erreur )

Figure 42 Diagramme séquence système Consulter client du référentiel

Description textuelle du sous cas « Modifier référentiel client»


Dans le tableau 32 qui suit, nous allons décrire le scénario détaillé de modification d’un client
du référentiel :

Cas d’utilisation Modifier référentiel client


Acteur Utilisateur BCT
Pré condition -L’utilisateur BCT identifié et autorisé
-Table « référentiel client » consultée
Post condition Modification effectuée
Scénario principal -L’utilisateur BCT introduit les modifications
-L’utilisateur BCT clique sur le bouton « Modifier »
-Le système met à jour la table « référentiel client »
Exception -L’utilisateur BCT introduit un type de donnée invalide
Le système affiche un message d’erreur

Tableau 32 Scénario Modifier un client du référentiel

Page 66
Chapitre II : Spécification des Exigences

Diagramme de Séquence modifier référentiel client

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 43:
Sequence modifier référentiel client

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (modifications)

alt succès

2:Afficher (modification effectuée)

erreur
3:Afficher (erreur )

Figure 43 Diagramme séquence système Modifier un client du référentiel

2.4.9. Raffinement du cas d’utilisation Gestion référentiel banque


La gestion des garanties crédit comporte 3 opérations : l’ajout d’une banque, la consultation
d’une banque, la modification d’une banque.
Le raffinement de ce cas d’utilisation est représenté dans la figure 44:

Page 67
Chapitre II : Spécification des Exigences

Gèrer Référentiel Banques


<<Utiisateur BCT>>

Consulter banque Ajouter banque

<<extend>>

Modifier banque

Figure 44 Raffinement du cas "Gestion Référentiel banques"

Description textuelle du sous cas « Ajouter référentiel banque»


Dans le tableau 33 qui suit, nous allons décrire le scénario détaillé de l’ajout d’une banque
dans le référentiel :

Cas Ajouter référentiel banque


d’utilisation
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout de banque effectué
Scénario -L’utilisateur BCT saisit les informations
principal -L’utilisateur BCT clique sur le bouton « Ajouter »
Le système enregistre la nouvelle banque et affiche « Ajout effectué »
Exception -L’utilisateur BCT ne renseigne pas les champs obligatoires, introduit un code qui
existe déjà ou saisit un type de donnée invalide
-L’utilisateur BCT clique sur le bouton « Ajouter »
Le système affiche un message d’erreur
Extension -

Tableau 33 Scénario Ajouter banque au référentiel

Page 68
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système ajouter référentiel banque

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 45:
Sequence ajouter référentiel banque

<<System>>
Refinancement

<<Utilisateur BCT>>

1:saisir (details référentiel banque)

alt
valides 2:Afficher (ajout accepté)

invalides
3:Afficher (erreur)

Figure 45 Diagramme séquence système Ajouter banque au référentiel

Description textuelle du sous cas « Consulter référentiel banque »


Dans le tableau 34 qui suit, nous allons décrire le scénario détaillé de consultation d’une
banque dans le référentiel :

Cas d’utilisation Consulter référentiel banque


Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario principal -L’utilisateur BCT saisit le code du référentiel à consulter
-Le système cherche dans la base de données
-Le système affiche les informations relatives au code introduit
Exception -L’utilisateur BCT introduit un code qui n’existe pas ou la table à consulter est
vide
-Le système cherche dans la base de données
Le système affiche « banque introuvable »

Tableau 34 Scénario consulter banque

Page 69
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système consulter référentiel banque

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 46:
Sequence consulter référentiel banque

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (critères référentiel banque)

alt critères valides

alt référentiel banque existant

2:Afficher_details référentiel banque()

référentiel banque inexistant


3: Afficher (référentiel banque
inexistant)

critères invalides
4:Afficher (erreur )

Figure 46 Diagramme séquence système Consulter banque

Page 70
Chapitre II : Spécification des Exigences

Description textuelle du sous cas « Modifier référentiel banque»


Dans le tableau 35 qui suit, nous allons décrire le scénario détaillé de modification d’une
banque dans le référentiel :

Cas d’utilisation Modifier référentiel banque


Acteur Utilisateur BCT
Pré condition -L’utilisateur BCT identifié et autorisé
-Table « référentiel banque » consultée
Post condition Modification effectuée
Scénario principal -L’utilisateur BCT introduit les modifications
-L’utilisateur BCT clique sur le bouton « Modifier »
-Le système met à jour la table « référentiel banque »
Exception -L’utilisateur BCT introduit un type de donnée invalide
Le système affiche un message d’erreur
Extension -

Tableau 35 Scénario Modifier banque

Diagramme de Séquence modifier référentiel banque

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 47:
Sequence modifier référentiel banque

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir (modifications)

alt succès

2:Afficher (modification effectuée )

erreur
3:Afficher (erreur)

Figure 47 Diagramme séquence système Modifier banque

Page 71
Chapitre II : Spécification des Exigences

2.4.10. Raffinement du cas d’utilisation Gestion opération de


refinancement
Le raffinement du cas d’utilisation « Consulter d’une opération de refinancement » est
représenté dans la figure 48:

Cosulter Refinancement

<<utilisateur BCT>>

Figure 48 Raffinement du cas "Consulter refinancement"

Description Textuelle du sous cas « Consulter refinancement »


Dans le tableau 36 qui suit, nous allons décrire le scénario détaillé de consultation d’une
opération de refinancement

Cas d’utilisation Consulter Refinancement


Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario -L’utilisateur BCT introduit le code de l’opération de refinancement
-Le système cherche dans la base de données
principal
-Le système affiche toutes les informations relatives au code introduit
Exception -L’utilisateur BCT introduit un code qui n’existe pas ou un type de donnée
invalide
Le système affiche un message d’erreur
Extension -

Tableau 36 Scénario Consulter opération de refinancement

Diagramme de Séquence Système de la consultation de l’opération de


refinancement

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 49:

Page 72
Chapitre II : Spécification des Exigences
Consulter operation refinancement

<<System>>
Refinancement

<<Utilisateur BCT>>

1:Saisir ( critères operation )

alt critères valides

alt operation existante


2:Afficher _details operation de
refinancement ( )

operation inexistante
3:Afficher(operation de refinancement
inexistante)

critères invalides
4:Afficher (erreur)

Figure 49 Diagramme séquence système Consulter opération refinancement

2.4.11. Raffinement du cas d’utilisation Gestion utilisateurs


La gestion des utilisateurs comporte 4 opérations : l’ajout d’un utilisateur, la consultation d’un
utilisateur, la modification d’un utilisateur et la suppression d’un utilisateur.
Le raffinement de ce cas d’utilisation est représenté dans la figure 50:

Page 73
Chapitre II : Spécification des Exigences

Gérer uti l i sateurs

<<Admi ni strateur>>

consul ter uti l i sateurs aj outer uti l i sateurs

<<extend>>
<<extend>>

Modi fi er uti l i sateurs


Suppri mer uti l i sateurs

Figure 50 Raffinement du cas "Gestion des utilisateurs"

Description textuelle du sous cas « Ajouter utilisateur »


Dans le tableau 37 qui suit, nous allons décrire le scénario détaillé de consultation d’une
opération de refinancement

Cas Ajouter utilisateur


d’utilisation
Acteur Administrateur
Précondition Administrateur identifié
Post-condition Utilisateur ajouté
Scénario- -L’administrateur saisit les informations concernant l’utilisateur -L’administrateur
nominal confirme l’ajout.
-Le système enregistre le nouvel utilisateur.
-Le système affiche « l’utilisateur est ajouté »
Exception -L’administrateur BCT saisit un code d’un utilisateur qui existe déjà, ne renseigne
pas les champs obligatoires ou introduit un type de donnée invalide
Le système affiche un message d’erreur
Extension -

Tableau 37 Scénario Ajouter utilisateur

Page 74
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système d’ajout utilisateur

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 51:
Sequence ajouter utilisateur

<<System>>
Refinancement

<<Administrateur BCT>>

1:saisir (details utilisateur)

alt
valides
2:Afficher( ajout accepté)

invalides

3:Afficher (erreur )

Figure 51 Diagramme séquence système Ajouter utilisateur

Description textuelle du sous cas « Consulter utilisateur »


Dans le tableau 38 qui suit, nous allons décrire le scénario détaillé de l’ajout d’un utilisateur

Cas d’utilisation Consulter utilisateur


Acteur Administrateur BCT
Pré condition Administrateur BCT identifié et autorisé
Post condition Consulter effectuée
Scénario principal -L’administrateur BCT saisit les critères de recherche d’un utilisateur
-Le système cherche dans la base de données
-Le système affiche tous les détails de l’utilisateur à rechercher
Exception -L’administrateur BCT saisit un code d’un utilisateur introuvable
Le système affiche un message d’erreur.
Extension -Modifier utilisateur
-Supprimer utilisateur

Tableau 38 Scénario Consulter utilisateur

Diagramme de Séquence Système de la consultation d’utilisateurs

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 52:

Page 75
Chapitre II : Spécification des Exigences
Sequence consulter utilisateur

<<System>>
Refinancement

<<Administrateur BCT>>

1:Saisir (critères utilisateur)

alt critères valides

alt utilisateur existant

2:Afficher _details utilisateur()

utilisateur inexistant
3: Afficher (utilisateur inexistant)

critères invalides
4:Afficher (erreur )

Figure 52 Diagramme séquence système Consulter utilisateur

Description textuelle du sous cas « Modifier utilisateur »


Dans le tableau 39 qui suit, nous allons décrire le scénario détaillé de la modification d’un
utilisateur

Cas d’utilisation Modifier un utilisateur


Acteur Administrateur
Pré condition Administrateur identifié.
Post-condition Modification effectuée
Scénario principal -L’administrateur saisit les modifications
-L’administrateur clique sur le bouton « Modifier »
-Le système met à jour la base de données
Exception -l’administrateur BCT introduit un type de donnée invalide
le système affiche « message d’erreur »
Extension -

Tableau 39 Scénario Modifier utilisateur

Page 76
Chapitre II : Spécification des Exigences

Diagramme de Séquence Système de modification utilisateur

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 53:
Sequence modifier utilisateur

<<System>>
Refinancement

<<Administrateur BCT>>

1:Saisir (modifications)

alt succès

2:Afficher (modification effectuée)

erreur
3:Afficher(erreur )

Figure 53 Diagramme séquence système Modifier utilisateur

Description textuelle du sous cas « Supprimer utilisateur »


Dans le tableau 40 qui suit, nous allons décrire le scénario détaillé de la modification d’un
utilisateur

Cas d’utilisation Supprimer utilisateur


Acteur Administrateur
Pré condition Administrateur identifié
Post-condition Utilisateur supprimé
Scénario-nominal -L’administrateur clique sur le bouton « Supprimer »
-Le système supprime l’utilisateur de la base de données
Exception Le système affiche une erreur
Extension -

Tableau 40 Scénario Supprimer Utilisateur

Diagramme de Séquence Système suppression utilisateurs

Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 54:

Page 77
Chapitre II : Spécification des Exigences

Sequence supprimer utilisateur

<<System>>
Refinancement

<<Administrateur BCT>>

1:click_bt supprimer utilisateur()

alt succès

2:Afficher (suppression effectuée )

erreur

3:Afficher (erreur)

Figure 54 Diagramme séquence système Supprimer utilisateur

3. Définition des opérations systèmes


Les événements système envoyés par les acteurs déclenchent des traitements internes
que nous appellerons opérations système.
L’ensemble de ces opérations système de tous les cas d’utilisation définit l’interface
publique du système, qui visualise le système comme une boîte noire offrant des services. Le
système pris dans son ensemble peut être représenté par une classe, avec le mot-clé «system»,
comme nous l’avons déjà fait dans les diagrammes de séquence système précédents.
Les opérations systèmes identifiés à partir des diagrammes de séquence système
établis auparavant sont représentées dans la figure 55 :

Page 78
Chapitre II : Spécification des Exigences

<<System>>
Refinancement

+ saisir ()
+ afficher ()
+ click_bt supprimer bon trésor ()
+ click_bt_supprimer_gar_bon_tresor ()
+ click_bt supprimer crédit ()
+ click_bt supprimer utilisateur ()
+ afficher_details oper refinancement ()
+ afficher_details crédit ()
+ afficher_details bon trésor ()
+ afficher details référentiel banque ()
+ afficher_details ref bon trésor ()
+ afficher_details référentiel client ()
+ afficher_details référentiel crédit ()
+ afficher_details utilisateur ()
+ selectionner ()

Figure 55: Liste des opérations Système

Pour découper l’ensemble des opérations en groupes cohérents, il serait également possible de
commencer à définir les cinq interfaces les plus importantes, comme représenté sur la figure
dans la figure 56 :

Page 79
Chapitre II : Spécification des Exigences

Figure 56 Liste des opérations système structurées en interfaces

4. Conclusion
A la fin de ce chapitre, nous avons pu identifier les principales fonctionnalités de notre
projet. Une liste des opérations que doit effectuer le système a été établie.
Dans le chapitre suivant, on va passer à l’analyse et à la conception des différents cas
d’utilisation.

Page 80
Chapitre III : Conception et Analyse

Chapitre III
Conception et Analyse

Page 81
Chapitre III : Conception et Analyse

1. Introduction
A partir des différentes méthodes identifiées dans le chapitre précédent, nous passons
à l’analyse des cas d’utilisation cas par cas.
Nous procédons comme suit :
Nous présentons tout d’abord une maquette pour chaque interface de notre application.
Ces maquettes vont nous permettre de définir les diagrammes de classes participantes qui
détermineront les classes de notre système.
Enfin, pour arriver à établir le diagramme de classe global, nous devons illustrer les
diagrammes séquence détaillés avant.
2. Analyse des cas d’utilisation
Nous présentons les types de diagrammes que nous allons exploiter afin d’analyser les
cas d’utilisation identifiés dans le chapitre dernier :

Diagramme de classe Participante: Ce diagramme est considéré comme un pilier


dans la modélisation orientée objet. Il offre une vue sur la structure interne du système et
donne un aperçu sur l’interaction de ses objets.

Il est composé de trois types de classes :

 Classe interface ou «Boundary»


 Classe contrôle ou «Control»
 Classe entité ou «Entity»

Diagramme de séquence détaillée: Ce diagramme schématise l’interaction entre le


système et les acteurs. Plusieurs types de messages peuvent être transmis entre les objets du
système.

Nous enchaînons avec l’analyse des cas d’utilisation présentés dans chapitre précédent.

2.1. Analyse du cas « Authentification »


2.1.1. Prototype de l’interface de l’authentification
L’interface de l’authentification comprend deux zones de texte pour saisir le login et le
mot de passe et une zone d’affichage pour dévoiler le nom et le prénom de l’utilisateur
associé au login tapé. Après avoir saisi les critères, l’utilisateur doit cliquer sur le bouton
« S’authentifier » pour se connecter et passer au menu principal.

Page 82
Chapitre III : Conception et Analyse

Figure 57 Prototype de l'interface de l'authentification

2.1.2. Diagramme de classe participante du cas de l’Authentification


L’interface sert de tableau de bord pour l’utilisateur, elle est associée à une classe de
contrôle qui a pour rôle de vérifier les champs ainsi que l’existence de l’utilisateur dans
l’entité « Utilisateur ».
Le diagramme résultant est communiqué dans la figure 58:

Figure 58 Diagramme de classe participante de l'Authentification

Page 83
Chapitre III : Conception et Analyse

2.1.3. Diagramme de Séquence détaillé du cas de l’Authentification


Le flux de messages se fait en commençant par l’interface qui lègue le message à la
classe de contrôle, qui à son tour le passe aux entités.
La figure 59 illustre le diagramme séquence détaillé relatif à l’authentification :
Authentification

<<Utilsateur BCT>> IU_Authentification Gest_Authentification Utilisateurs

alt Saisie correcte

1:Saisir(login, mot de passe)

2:Prise en charge click ( ) 3:Consulter ( )

alt Utilisateur trouvé

5:Afficher (connexion effectuée)

Utilisateur non trouvé

6:Afficher (erreur)

Saisie incorrecte Afficher (champ incohérent, veuillez


réessayer à nouveau)

Figure 59 Diagramme séquence détaillé de l'authentification

2.2. Analyse du cas « Gestion Portefeuille de crédits »


2.2.1. Prototypes des interfaces du cas Gestion Portefeuille de crédits
Comme on peut le voir dans le premier prototype qui suit, l’interface de l’ajout d’un
crédit au portefeuille est composée de neuf éléments texte qui représentent respectivement : la
date de déclaration, la banque, le bénéficiaire, la forme de crédit, la date de déblocage, le
montant, la date d’échéance, l’encours et la date de garantie. Pour ajouter un nouveau crédit
dans le portefeuille, il suffit de remplir tous les champs à l’exception de la date de garantie et
cliquer sur le bouton « Ajouter ».
Par contre, dans le deuxième prototype, on remarque que l’interface est divisée en
deux blocs. La première comporte six champs qui représentent les critères de recherche. On
cherche un crédit en tapant le libellé de la banque d’où il provient, sa forme, son bénéficiaire,
sa date de déblocage et enfin sa date d’échéance. Un clic sur le bouton « Consulter » permet

Page 84
Chapitre III : Conception et Analyse

d’afficher dans le deuxième bloc le crédit recherché. Outre les critères cités auparavant, six
autres champs sont représentés dans l’interface. Il s’agit de la date de déclaration, du montant,
de l’encours, de l’état, de la date garantie et du rejet. On a deux possibilités d’opérations :
Modifier ou Supprimer.
Et enfin le dernier prototype symbolise la sélection des tombées. L’utilisateur doit
introduire une date, clique sur le bouton supprimer et le système supprime tous les crédits
ayant la date d’échéance inférieure à la date saisie.

Figure 60 Prototype de l'interface "Ajouter crédit au portefeuille"

Figure 61 Prototype de l'interface "Consulter crédit du portefeuille"

Page 85
Chapitre III : Conception et Analyse

Figure 62 Prototype de l'interface "Sélection des tombées"

2.2.2. Diagramme de classe Participante du cas Gestion Portefeuille de


crédits

L’ajout, la consultation, la mise à jour et la sélection des tombées nécessitent une


interface chacun, une classe contrôle et deux entités « Portefeuille de crédits » et « Encours ».
La figure 63 illustre le diagramme de classe participante relatif à la gestion du
portefeuille de crédits :

Page 86
Chapitre III : Conception et Analyse

Figure 63 Diagramme de classe participante "Gestion portefeuille de crédits"

2.2.3. Diagramme de séquence détaillé du cas Gestion Portefeuille de


crédits

Le flux des messages entre les différents objets du système est représenté dans le
diagramme illustré dans la figure 64:

Page 87
Chapitre III : Conception et Analyse
Diag sequence portefeuille crédit

<<Utilisateur BCT>> IU_menu principal IU_consulter crédit IU_ajouter crédit IU_selection des tombées GEST_gestion portefeuille portefeuille crédit encours crédit référentiel client référentiel banque référentiel crédit
crédit

1:Dérouler liste ( )

2:Selectionner (opération)

opt [consulter]

3:Saisir( critères crédit)


4:Click_bt consulter ( )
4:Prise en charge click ( ) 5:Consulter( )
6:Consulter ( )

alt crédit existant


7:Afficher _details crédit( )

opt [modifier]

8:Saisir (modifications)

9:click_bt modifier ( ) 10:Prise en charge click ( ) 11:Mise à jour ( )


12:Mise à jour ( )

alt erreur
13:Afficher (erreur)

succès

14:Afficher (modification effectuée)

opt [supprimer] 15:Click_bt supprimer ( ) 16:prise en charge click ( ) 17:Supprimer ( )


18:Supprimer ( )
alt succès
19:Afficher (suppression effectuée)

erreur
20:Afficher ( erreur)

crédit inexistant

21:Afficher (crédit inexistant )

opt [ajouter crédit]

22:Saisir(critères crédit) 25:Ajouter ( )


24:prise en charge click ( )
23:click bt ajouter ( ) 26:Ajouter ( )
27:consulter ()
28:consulter ( )
29:consulter ( )

alt
succès
30:Afficher (ajout effectué)

erreur
31:Afficher(erreur)

opt [selection des tombées]


32:Saisir(date)
33:Click_bt supprimer ( ) 34:Prise en charge click ( ) 35:Supprimer ( )
36:Supprimer ( )

alt date crédit < date du jour

37:Afficher (suppression effectuée)

date crédit > date du jour

38:Afficher(pas de crédit à supprimer)

Figure 64 Diagramme séquence détaillé "Gestion portefeuille crédits"

Page 88
Chapitre III : Conception et Analyse

2.3. Analyse du cas « Gestion Encours Bon du trésor »

2.3.1. Prototypes des interfaces du cas Gestion Encours Bon du trésor


La gestion de l’Encours des Bons du trésor est divisée en 3 interfaces.
Le premier prototype correspond à l’interface de l’ajout d’un bon du trésor. On y
distingue six zones de saisie. Pour ajouter un bon du trésor, il faut impérativement remplir les
champs suivants : la date d’encours, la banque, le code Isin, l’encours et la catégorie. La date
de mise en garantie est modifiée lorsque le bon du trésor est pris en garantie.
Nous tournons maintenant vers le deuxième prototype qui modélise la consultation
d’un bon du trésor. Il est aussi composé de deux blocs, le premier pour les critères de
recherche à savoir la banque, le code Isin et la date d’encours. Un clic sur le bouton
« Consulter » permet d’afficher les caractéristiques du bon à rechercher, outre abordés dans la
section critères de recherche, on cite l’encours, la catégorie, la date mise en garantie et la date
d’échéance.
Enfin, la dernière interface consiste à vérifier si la date d’échéance d’un bon du trésor
est encore valide ou pas.

Figure 65 Prototype de l'interface Ajouter bon du trésor

Page 89
Chapitre III : Conception et Analyse

Figure 66 Prototype de l'interface "Consulter bon du trésor"

Figure 67 Prototype de l'interface "Vérifier échéance bon du trésor"

2.3.2. Diagramme de classe participante du cas Gestion Encours bon du


trésor
L’ajout, la consultation, la mise à jour et la sélection des tombées nécessitent une
interface chacun, une classe contrôle et une entité « Encours bon du trésor »
Le diagramme obtenu est illustré dans la figure 68 :

Page 90
Chapitre III : Conception et Analyse

Figure 68 Diagramme classe global "Gestion encours bon du trésor"

2.3.3. Diagramme de séquence détaillé du cas «Gestion encours Bon du


trésor »
Le flux des messages entre les différents objets du système est représenté dans le
diagramme illustré dans la figure 69:

Page 91
Chapitre III : Conception et Analyse
sequence encours bon du trésor

<<Utilisateur BCT>> IU_menu principal IU_consulter bon trésor IU_ajouter bon trésor IU_verifier échéance GEST_gestion encours encours bon du trésor référentiel banque référentiel bon du trésor
bon du trésor

1:Dérouler liste ( )

2:Selectionner (opération)

opt [consulter]

3:Saisir( critères bon du trésor)


4:Click_bt consulter ( )
5:Prise en charge click ( ) 6:Consulter ( )

alt bon trésor existant

7:Afficher _details bon du trésor ( )

opt [modifier]

8:Saisir (modifications)

9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )
alt erreur
12:Afficher (erreur)
succès

13:Afficher (modification effectuée)

opt [supprimer]
14:Click_bt supprimer ( ) 15:prise en charge click ( ) 16:Supprimer ( )
alt succès

17:Afficher (suppression effectuée)

erreur 18:Afficher ( erreur)

bon trésor inexistant

19:Afficher (bon du trésor inexistant )

opt [ajouter bon trésor]

20:Saisir(details bon du trésor) 22:prise en charge click ( ) 23:Ajouter ( )


21:click bt ajouter ( ) 24:consulter ( )
25:consulter( )
alt succès

26:Afficher (ajout effectué)

erreur
27:Afficher(erreur)

opt [verifier échéance]


28:Saisir(date du jour)
30:Prise en charge click ( )
29:Click_bt verifier( ) 31:Consulter( )

alt date crédit < date du jour

32:Afficher (bon trésor a atteint


l'échéance)

date crédit > date du jour

33:Afficher(bon du trésor n'a pas atteint l'


échéance)

Figure 69 Diagramme séquence detaillé "Gestion encours bon du trésor"

Page 92
Chapitre III : Conception et Analyse

2.4.Analyse du cas « Gestion Garanties crédits »


2.4.1. Prototype du cas « Gestion Garanties crédits »
Dans la partie suivante, nous allons traiter l’une des parties les plus importantes de
notre sujet.
Le prototype proposé pour la gestion des garanties de crédits comporte deux parties.
La première partie correspond à la consultation d’une opération de refinancement.
L’utilisateur introduit la date de l’opération et clique sur le bouton « Consulter » pour voir les
caractéristiques de l’opération relative à la date saisie à savoir le code de l’opération,
l’emprunteur, le montant, le taux, la durée, la date d’échéance et la date de règlement.
La deuxième partie correspond à la gestion des créances. Une liste des crédits s’affiche
depuis le portefeuille de crédits ayant le même emprunteur de l’opération de refinancement
consultée, l’utilisateur choisit les crédits qu’il veut prendre pour garantie et clique sur Ajouter
pour insérer les données dans la table Garantie de crédits. L’interface permet d’avoir la
possibilité de modifier ou supprimer une garantie.
Une mise à jour dans la table Portefeuille de crédit est effectuée, la date de mise en
garantie prend la date du jour.

Figure 70 Prototype de l'interface "Gestion garanties crédits"

Page 93
Chapitre III : Conception et Analyse

2.4.2. Diagramme de classe participante du cas Gestion garanties crédits

L’ajout, la consultation et la mise à jour nécessitent une interface chacun, une classe
contrôle et quatre entités « Portefeuille de crédits », « Encours crédit », « Garantie Crédits »
et « Opération refinancement »

Le diagramme obtenu est illustré dans la figure 71 ci-dessous

Figure 71 Diagramme classe participante "Gestion garanties crédits"

Page 94
Chapitre III : Conception et Analyse

2.4.3. Diagramme de séquence détaillé du cas « Gestion Garanties


Crédits »
Le flux des messages entre les différents objets du système est représenté dans la
figure 72 présentée ci-dessous:
DiagrammeSequence garantie crédit

<<Utilisateur BCT>> IU_menu principal IU_consulter garantie IU_consulter operation GEST_gestion garantie encours crédit garantie crédit operation refinancement portefeuille crédit
crédit refinancement crédit

1:Dérouler liste ( )

2:Selectionner (opération)

opt [consulter]

3:Saisir( critères garantie crédit)


4:Click_bt consulter ( )
5:Prise en charge click ( ) 6:Consulter ( )

alt garantie crédit existante

7:Afficher_details garantie crédit ( )

opt [Modifier]
8:Saisir (modifications)
9:Click_bt modifier ( )
10:Prise en charge click ( )
11:Mise à jour ( )

alt erreur
12:Afficher (erreur)

succès

13:Afficher( modification effectuée)

opt [Supprimer]
14:Click_bt supprimer 15:Prise en charge click( ) 16:Supprimer ( )

alt succès

17:Afficher (suppression effectuée)

erreur
18:Afficher (erreur)

garantie crédit inexistante 19:Afficher ( garantie crédit inexistante)

opt [ajout garantie crédit]

20:Saisir (details garantie crédit) 22:Ajouter ( )

21:Click_bt ajouter ( ) 23:Ajouter ( )


24:Ajouter ( )
25:Ajouter ( )
alt succès
26:Afficher (succès)

erreur
27:Afficher (erreur)

opt [consulter operation refinancement]


28:saisir (critères operation
refinancement)
29:Click_bt consulter operation
refinancement( ) 30:Prise en charge click( )
31:Consulter ( )

alt succès
32:Afficher_details operation de
refinancement( )

erreur

33:Afficher (erreur)

Figure 72 Diagramme séquence détaillé "Gestion garantie crédits"

Page 95
Chapitre III : Conception et Analyse

2.5.Analyse du cas « Gestion Garanties Bons du trésor »


2.5.1. Prototype de l’interface du cas « Gestion garanties Bons du trésor »
Nous abordons la deuxième plus importante partie de notre sujet. Il s’agit de la gestion
des bons du trésor.
Tout comme l’interface de gestion des garanties de crédits, elle est composée de deux
parties.
La première partie concerne la consultation de l’opération de refinancement.
Et la deuxième partie correspond à la gestion des bons du trésor. Une liste des bons du
trésor est affichée depuis l’encours, l’utilisateur choisit les bons qu’il veut prendre en garantie
et le système les affichent. On distingue neuf zones de texte : le code de l’opération, le
numéro de l’opération, le code Isin, la date de l’opération, le donneur, le receveur, le nombre
de bons, la date de règlement et la date de prise en garantie. Ils sont ensuite insérés dans la
table « Garanties bons du trésor ».
Il est possible de modifier ou supprimer une garantie.
Une mise à jour de la date prise en garantie dans la table « Encours bon du trésor »

Figure 73 Prototype de l'interface "Gestion garantie bon du trésor"

Page 96
Chapitre III : Conception et Analyse

2.5.2. Diagramme de classe participante du cas « Gestion Garanties Bons du


trésor »
L’ajout, la consultation et la mise à jour nécessitent une interface chacun, une classe
contrôle et deux entités « Encours bon du trésor » et « Garanties bons du trésor ».
Le diagramme obtenu est illustré dans la figure 74 ci-dessous

Figure 74 Diagramme de classe participante "Gestion garanties bon du trésor"

Page 97
Chapitre III : Conception et Analyse

2.5.3. Diagramme de Séquence détaillée du cas « Gestion Garanties bons du


trésor »
Le flux des messages entre les différents objets du système est représenté dans la
figure 75 jointe ci-dessous
DiagrammeSequence garantie bon du trésor

<<Utilisateur BCT>> IU_menu principal IU_consulter garantie bon IU_consulter operation GEST_gestion garantie encours bon du trésor garantie bon du trésor operation refinancement
trésor refinancement bon du trésor

1:Dérouler liste ( )

2:Selectionner (opération)

opt [consulter]

3:Saisir( critères garantie bon du trésor)


4:Click_bt consulter ( )
5:Prise en charge click ( ) 6:Consulter ( )

alt garantie bon trésor existante

7:Afficher_details garantie bon trésor ( )

opt [Modifier]
8:Saisir (modifications)
9:Click_bt modifier ( )
10:Prise en charge click ( )
11:Mise à jour ( )

alt erreur
12:Afficher (erreur)

succès

13:Afficher( modification effectuée)

opt [Supprimer]
14:Click_bt supprimer 15:Prise en charge click( )

alt succès
16:Supprimer ( )
17:Afficher (suppression effectuée)

erreur
18:Afficher (erreur)

garantie bon trésor inexistante


19:Afficher ( garantie bon trésor
inexistante)

opt [ajout garantie bon trésor]

20:Saisir (details garantie bon trésor)


22:Ajouter ( )

21:Clik bt ajouter ( ) 23:Ajouter ( )


24:Ajouter ( )

alt succès

25:Afficher (succès)

erreur
26:Afficher (erreur)

opt [consulter operation refinancement] 27:saisir (critères operation


refinancement)
28:Click_bt consulter operation
refinancement ( ) 29:prise en charge click ( )
30:Consulter ( )

alt succès
31:Afficher(details operation de
refinancement)
erreur

32:Afficher(erreur)

Figure 75 Diagramme séquence détaillé "Gestion garanties Bon du trésor"

Page 98
Chapitre III : Conception et Analyse

2.6.Analyse du cas « Gestion Référentiel Banques »


2.6.1. Prototypes des interfaces du cas Gestion Référentiel Banques
Deux interfaces sont requises pour la gestion du référentiel des banques, une pour
l’ajout d’une banque et l’autre pour la consultation, la modification et la suppression d’une
banque.
Dans les deux cas, on a sept éléments texte qui représentent respectivement : le code
de la banque, le libellé, le téléphone, le fax, l’abréviation, l’adresse et la catégorie.

Figure 76 Prototype de l'interface « Ajouter banque »

Figure 77 Prototype de l'interface "Consulter banque"

Page 99
Chapitre III : Conception et Analyse

2.6.2. Diagramme de classe participante du cas « Gestion Référentiel


Banques »
L’ajout, la consultation et la mise à jour nécessitent une interface chacun, une classe
contrôle et une entité « Encours bon du trésor »
Le diagramme obtenu est illustré dans la figure 78 ci-dessous

Figure 78 Diagramme de classe participante "Gestion référentiel banque"

2.6.3. Diagramme de séquence détaillé du cas « Gestion Référentiel


Banques »
Le flux des messages entre les différents objets du système est représenté dans la
figure 79 jointe ci-dessous :

Page 100
Chapitre III : Conception et Analyse
DiagrammeSequence référentiel banque

<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel IU_ajouter banque GEST_gestion référentiel banque
banque banque

1:Dérouler liste ( )

2:Selectionner (opération)

opt [consulter]

3:Saisir( critères banque)


4:Click_bt consulter ( )
5:Prise en charge click ( ) 6:Consulter ( )

alt banque existante

7:Afficher _details banque ( )

opt [modifier]
8:Saisir (modifications)

9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )

alt erreur 12:Afficher (erreur)

succès

13:Afficher (modification effectuée)

banque inexistante

14:Afficher (banque inexistante)

opt [ajouter bon trésor]

15:Saisir(critères banque)
16:click bt ajouter ( ) 17:prise en charge click ( ) 18:Ajouter ( )

alt succès

19:Afficher (ajout effectué)

erreur
20:Afficher(erreur)

Figure 79 Diagramme séquence détaillé "Gestion référentiel banque"

Page 101
Chapitre III : Conception et Analyse

2.7.Analyse du cas « Gestion Référentiel Bons Du trésor »


2.7.1. Prototypes des interfaces du cas « Gestion Référentiel Bons du Trésor
Le premier prototype qu’on présente comporte le code du bon du trésor, le libellé, la
date d’échéance, l’unité, le taux nominal et la catégorie. Un clic sur le bouton « Ajouter » est
nécessaire pour insérer les données dans la table « Bon du trésor ».
Le deuxième prototype a pour rôle de donner un aperçu sur la future interface de
consultation d’un bon du trésor. On peut y effectuer des modifications ou supprimer un bon
du trésor.

Figure 80 Prototype de l'interface "Ajouter bon du trésor"

Page 102
Chapitre III : Conception et Analyse

Figure 81 Prototype de l'interface "Consulter bon du trésor"

2.7.2. Diagramme de classe participante du cas « Gestion Référentiel Bon


du trésor »
L’ajout, la consultation et la mise à jour nécessitent une interface chacun, une classe
contrôle et d’une entité «Bon du trésor ».
Le diagramme obtenu est illustré dans la figure 82 jointe ci-dessous

Page 103
Chapitre III : Conception et Analyse

Figure 82 Diagramme de classe participante "Gestion référentiel Bon du trésor"

2.7.3. Diagramme de séquence détaillé du cas « Gestion Référentiel Bons du


trésor »
Le flux des messages entre les différents objets du système est représenté dans la
figure 83 jointe ci-dessous :

Page 104
Chapitre III : Conception et Analyse
DiagrammeSequence référentiel bon trésor

<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel IU_ajouter bon trésor GEST_gestion référentiel bon du trésor
bon trésor bon du trésor

1:Dérouler liste ( )

2:Selectionner (opération)

opt [consulter]

3:Saisir( critères bon du trésor)


4:Click_bt consulter ( )
5:Prise en charge click ( ) 6:Consulter ( )

alt bon trésor existant

7:Afficher _details bon du trésor ( )

opt [modifier]
8:Saisir (modifications)

9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )

alt erreur 12:Afficher (erreur)

succès

13:Afficher (modification effectuée)

bon trésor inexistant

14:Afficher (bon du trésor inexistant )

opt [ajouter bon trésor]

15:Saisir(details bon du trésor)

16:click bt ajouter ( ) 17:prise en charge click ( ) 18:Ajouter ( )


alt succès

19:Afficher (ajout effectué)

erreur
20:Afficher(erreur)

Figure 83 Diagramme séquence détaillé "Gestion référentiel bon du trésor"

Page 105
Chapitre III : Conception et Analyse

2.8.Analyse du cas « Gestion Référentiel Clients »


2.8.1. Prototypes des interfaces du cas « Gestion Référentiel Clients »
Les deux prototypes d’ajout et de consultation d’un client contiennent deux zones de
texte intitulées respectivement : identifiant et raison sociale.
Trois boutons sont mis à la disposition de l’utilisateur dans l’interface de consultation:
Consulter, Modifier et Supprimer et un seul bouton Ajouter dans l’interface de l’ajout d’un
client.

Figure 84 Prototype de l'interface "Ajouter client"

Page 106
Chapitre III : Conception et Analyse

Figure 85 Prototype de l'interface "Consulter client"

2.8.2. Diagramme de classe participante du cas « Gestion Référentiel


Clients »
L’ajout, la consultation et la mise à jour nécessitent une interface chacun, une classe
contrôle et une entité « Clients ».
Le diagramme obtenu est illustré dans la figure 86 jointe ci-dessous

Page 107
Chapitre III : Conception et Analyse

Figure 86 Diagramme de classe participante "Gestion référentiel Client"

2.8.3. Diagramme de séquence détaillé du cas « Gestion Référentiel


Clients »
Le flux des messages entre les différents objets du système est représenté dans la
figure 87 jointe ci-dessous :

Page 108
Chapitre III : Conception et Analyse
DiagrammeSequence référentiel client

<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel IU_ajouter client GEST_gestion référentiel client
client client

1:Dérouler liste ( )

2:Selectionner (opération)

opt [consulter]

3:Saisir( critères client)

4:Click_bt consulter ( )
5:Prise en charge click ( ) 6:Consulter ( )

alt client existant

7:Afficher _details client ( )

opt [modifier]

8:Saisir (modifications)

9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )

alt erreur
12:Afficher (erreur)
succès

13:Afficher (modification effectuée)

client inexistant

14:Afficher (client inexistant )

opt [ajouter client]

15:Saisir(details client)

16:click bt ajouter ( ) 17:prise en charge click ( ) 18:Ajouter ( )


alt succès

19:Afficher (ajout effectué)

erreur
20:Afficher(erreur)

Figure 87 Diagramme séquence détaillé "Gestion référentiel clients"

Page 109
Chapitre III : Conception et Analyse

2.9.Analyse du cas « Gestion Référentiel crédits »


2.9.1. Prototypes des interfaces du cas « Gestion Référentiel Crédits »
Les deux prototypes d’ajout et de consultation d’un crédit contiennent deux zones de
texte intitulées respectivement : code, libellé court et libellé long.
Trois boutons sont mis à la disposition de l’utilisateur dans l’interface de consultation:
Consulter, Modifier et Supprimer et un seul bouton Ajouter dans l’interface de l’ajout d’un
crédit.

Figure 88 Prototype de l'interface "Ajouter crédit"

Page 110
Chapitre III : Conception et Analyse

Figure 89 Prototype de l'interface "Consulter crédit"

2.9.2. Diagramme de classe participante du cas « Gestion Référentiel


crédits »
L’ajout, la consultation et la mise à jour nécessitent une interface chacun, une classe
contrôle et une entité «Crédit ».
Le diagramme obtenu est illustré dans la figure 90 jointe ci-dessous

Page 111
Chapitre III : Conception et Analyse

Figure 90 Diagramme de classe participante "Gestion référentiel crédits"

2.9.3. Diagramme de séquence détaillé du cas « Gestion Référentiel


Crédits »
Le flux des messages entre les différents objets du système est représenté dans la
figure 91 jointe ci-dessous

Page 112
Chapitre III : Conception et Analyse
DiagrammeSequence référentiel crédit

<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel IU_ajouter crédit GEST_gestion référentiel crédit
crédit crédit

1:Dérouler liste ( )

2:Selectionner (opération)

opt [consulter]

3:Saisir( critères crédit)

4:Click_bt consulter ( )
5:Prise en charge click ( ) 6:Consulter ( )

alt crédit existant

7:Afficher _details crédit ( )

opt [modifier]

8:Saisir (modifications)

9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )

alt erreur 12:Afficher (erreur)

succès

13:Afficher (modification effectuée)

crédit inexistant

14:Afficher (crédit inexistant )

opt [ajouter crédit]

15:Saisir(details crédit)

16:click bt ajouter ( ) 17:prise en charge click ( ) 18:Ajouter ( )


alt succès

19:Afficher (ajout effectué)

erreur

20:Afficher(erreur)

Figure 91 Diagramme séquence détaillé "Gestion référentiel crédits"

Page 113
Chapitre III : Conception et Analyse

2.10. Analyse du cas « Gestion des utilisateurs »


2.10.1. Prototypes des interfaces du cas de « Gestion des utilisateurs »
La gestion des utilisateurs comprend deux interfaces.
L’ajout d’un utilisateur consiste à remplir les champs présents dans l’interface à savoir
le login, le mot de passe, le profil, le nom et le prénom.
Et la consultation d’un utilisateur se fait en saisissant le critère de recherche qu’est le
profil. L’administrateur clique ensuite sur le bouton « Consulter » et le système lui affiche les
données relatives de l’utilisateur associé au profil saisi.
L’administrateur a aussi la possibilité de modifier et supprimer un utilisateur.

Figure 92 Prototype de l'interface "Ajouter utilisateur"

Figure 93 Prototype de l'interface "Consulter utilisateur"

Page 114
Chapitre III : Conception et Analyse

2.10.2. Diagramme de classe participante du cas « Gestion des


utilisateurs »
L’ajout, la consultation et la mise à jour nécessitent une interface chacun, une classe
contrôle et une entité « Utilisateurs ».
Le diagramme obtenu est illustré dans la figure 94 jointe ci-dessous

Figure 94 Diagramme de classe participante "Gestion utilisateurs"

2.10.3. Diagramme de séquence détaillé du cas « Gestion des


utilisateurs »
Le flux des messages entre les différents objets du système est représenté dans la
figure 95 jointe ci-dessous :

Page 115
Chapitre III : Conception et Analyse
DiagrammeSequence utilisateur

<<Administrateur BCT>> IU_menu principal IU_consulter utilisateur IU_ajouter utilisateur GEST_gestion utilisateur utilisateur

1:Dérouler liste ( )

2:Selectionner (opération)

opt [consulter]

3:Saisir( critères utilisateur)


4:Click_bt consulter ( )
5:Prise en charge click ( ) 6:Consulter ( )

alt utilisateur existant


7:Afficher_details utilisateur ( )

opt [modifier]

8:Saisir (modifications)

9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )
alt erreur
12:Afficher (erreur)
succès

13:Afficher (modification effectuée)

opt [supprimer] 14:Click_bt supprimer ( ) 15:prise en charge click ( ) 16:Supprimer ( )

alt succès

17:Afficher (suppression effectuée)

erreur 18:Afficher ( erreur)

utilisateur inexistant

19:Afficher (utilisateur inexistant )

opt [ajouter utilisateur]

20:Saisir(details utilisateur)
21:click bt ajouter ( ) 22:prise en charge click ( ) 23:Ajouter ( )
alt succès

24:Afficher (ajout effectué)

erreur
25:Afficher(erreur)

Figure 95 Diagramme séquence détaillé "Gestion utilisateurs"

Page 116
Chapitre III : Conception et Analyse

2.11. Analyse du cas « Consulter Opération de refinancement »


2.11.1. Prototypes des interfaces du cas « Consulter Opération de
refinancement »
Le prototype qui suit sert à modéliser l’opération de refinancement.

Figure 96 Prototype de l'interface "Consulter opération de refinancement"

2.11.2. Diagramme de classe participante du cas « Consulter


Opération de refinancement »
L’ajout, la consultation et la mise à jour nécessitent une interface chacun, une classe
contrôle et une entité « Opération de refinancement ».
Le diagramme obtenu est illustré dans la figure 97 jointe ci-dessous

Page 117
Chapitre III : Conception et Analyse

Figure 97 Diagramme de classe participante "Consulter opération de


refinancement"

2.11.3. Diagramme de séquence détaillé du cas « Consulter Opération


de refinancement »
Le flux des messages entre les différents objets du système est représenté dans la
figure 98 jointe ci-dessous :

Figure 98 Diagramme séquence détaillé "Consulter opération de refinancement"

Page 118
Chapitre III : Conception et Analyse

3. Présentation du diagramme de classe global


Afin de fournir une vue globale sur notre système, nous établissons dans la figure 99
qui suit le diagramme de classe global

Page 119
Chapitre III : Conception et Analyse
référentiel bon trésor
- codeisin : String
référentiel crédit
- lib : String
- code crédit : String - unite : int
- libl_court : String - taux_nominal : int
- libl_long : String - categorie : String
+ consulter () + consulter ()
+ mise à jour () + mise à jour ()
+ ajouter () + ajouter ()

1..1
1..1

encours crédit
verifier
- code encours : String
examiner - date_encours : Date
1..1
- encours : float
+ consulter () encours bon du trésor
1..1 + mise à jour ()
- id_encours bon trésor : int
+ ajouter ()
- date_encours : Date
portefeuille crédit + supprimer ()
- categorie : String
...
- id_portefeuille crédit : int 1..* - encours : float
- forme crédit : String - date_échéance : int
- date-deblocage : Date + consulter ()
- date-echeance : Date correspondre référentiel banque + mise à jour ()
- montant : float + ajouter ()
- code banque : String
- etat : String + supprimer ()
1..* - lib : String
- code rejet : String 1..1 ...
- tel : int
- flag rejet : char 1..*
- fax : int 1..*
+ consulter () - abréviation : String
+ mise à jour () - adresse : String chercher
+ ajouter () référer 1..1 - categorie : String extraire
1..* 1..1
+ supprimer ()
+ consulter ()
+ mise à jour () 1
+ ajouter ()
garantie bon trésor
1..* - id_garantie bon trésor : int
importer - nbr_bon : int
- date mremb : Date
- date échéance : Date
1 + consulter ()
+ mise à jour ()
garantie crédit operation de refinancement
+ ajouter ()
- id_ garantie crédit : int - code_operation : String + supprimer ()
- montant des garanties : float 1..1 - date_operation : Date prendre
appartenir 1..* couvrir 1..1 1..*
- date_date_mremb : Date - donneur : String
- date échéance : Date - receveur : String
+ consulter () - montant : float
+ mise à jour () - num_operation : int
+ ajouter () - taux : int
+ supprimer () - duree : float 0..*
- date échéance : int
+ consulter ()

0..*
0..*

historique

1..1

référentiel client
- identifiant : String
0..*
- raison_soc : int
+ consulter () USER
+ mise à jour () - code_user : String
+ ajouter () - nom,prenom : String
... - login : String
- mot de passe : String
- mail : String
0..* - profil : String 0..*
+ consulter ()
+ mise à jour ()
+ ajouter ()
archive + supprimer () enregistrement
...

Administrateur
- id_administrateur : int
- code_ad : String

Figure 99 Diagramme de classe global

Page 120
Chapitre III : Conception et Analyse

4. Conclusion
L’analyse des cas d’utilisation ainsi que la conception rencontrés au cours de ce
chapitre nous permettent désormais d’identifier les classes nécessaires pour la réalisation de
notre projet. Nous allons alors détailler dans le chapitre 4, les différentes phases de réalisation
de notre projet.

Page 121
Chapitre IV : Implémentation

Chapitre IV :
Implémentation

Page 122
Chapitre IV : Implémentation

1. Introduction
Ce chapitre a pour but de décrire les solutions techniques retenues pour
l’implémentation de notre projet.
Nous commençons par générer notre base de données relationnelle en se basant sur le
diagramme de classe global établie dans le chapitre précédent. Par la suite, on passe à la
description de l’architecture physique de notre application en établissant un diagramme de
déploiement. Et enfin, nous allons présenter des captures d’écrans des interfaces de notre
application pour avoir une idée générale sur son fonctionnement.
2. Génération des tables
Dans ce qui suit, nous allons présenter les tables de notre base de données :

Tableau 41 Liste des tables de la base de données

Table portefeuille crédit


Attributs Type Commentaire
ID_portefeuilleCrédit NUMBER Clé primaire
Identifiant VARCHAR -Clé étrangère (Référentiel
clients)
-Désigne propriétaire du crédit
BQ VARCHAR -Clé étrangère (Référentiel
banques)
- Désigne la banque d’où
provient le crédit
Forme crédit VARCHAR Forme du crédit
Date_deb DATE Date déblocage du crédit
Date_ech DATE Date d’échéance du crédit
Montant NUMBER Montant initial du crédit
Etat VARCHAR Indique si le crédit est pris en
garantie ou pas
Date_mremb DATE Date mise en garantie
Code rejet VARCHAR Indique le code du motif du
rejet
Flag rejet VARCHAR Si l’utilisateur a des doutes sur
crédit, il affecte la lettre « R »
dans l’attribut Flag rejet
Code_encours VARCHAR Clé étrangère (Table

Page 123
Chapitre IV : Implémentation

EncoursCrédit)

Table EncoursCrédits

Attributs Type Commentaires


Code_encours VARCHAR Clé primaire
Encours NUMBER Encours crédit
Date_Encous DATE Date de l’encours

Table garanties crédits

Attributs Types Commentaires


ID_GarantieCrédits NUMBER Clé primaire
Code_oper NUMBER -Clé étrangère (Table
OpérationRefinancement)
-Désigne le code de l’opération
Date_oper DATE -Clé étrangère (Table
OpérationRefinancement)
-Désigne la date de l’opération
Donneur VARCHAR -Banque centrale de Tunisie
Receveur VARCHAR -Désigne la banque à qui la
banque centrale va accorder un
crédit.
Num_oper NUMBER Clé étrangère (Table
OpérationRefinancement)
Forme crédit VARCHAR Forme du crédit
Montant NUMBER Montant initial du crédit
Ident NUMBER -Clé étrangère (Référentiel
clients)
-Désigne le propriétaire du
crédit
Date_deb DATE -Date déblocage du crédit
Date_ech DATE -Date d’échéance du crédit
Date_mremb DATE -Date mise en garantie
Montant des garanties NUMBER Montant total des garanties

Page 124
Chapitre IV : Implémentation

Table référentiel crédit

Attributs Type Commentaire


CodeFC NUMBER Clé primaire
Libc VARCHAR Libellé court
Libellé VARCHAR Libellé long

Table encours bon du trésor

Attributs Types Commentaires


ID_EncoursBonDuTrésor NUMBER Clé primaire
Date_encours DATE Date encours du bon du trésor
BQ VARCHAR -Clé étrangère (Référentiel
banques)
-désigne la banque d’où
provient le bon du trésor
Code isin NUMBER -Clé étrangère (Référentiel Bon
du trésor)
Categ VARCHAR Long terme/court terme
Date_misg DATE Date mise en garantie
Encours NUMBER Encours du bon du trésor

Table garanties bon du trésor

Attributs Type Commentaires


ID_GarantiesBonDuTrésor NUMBER Clé primaire
Code_oper NUMBER Clé étrangère (Table
OpérationRefinancement)
Date_oper DATE Clé étrangère (Table
OpérationRefinancement)
Donneur VARCHAR Banque centrale de Tunisie
Receveur VARCHAR -Désigne la banque à qui la
banque centrale va accorder un
crédit.
Num_oper NUMBER Clé étrangère (Table
OpérationRefinancement)
Code isin NUMBER Clé étrangère(Référentiel bon

Page 125
Chapitre IV : Implémentation

du trésor)
Nbr_bon NUMBER Nombre de bons pris en garantie
Date_mremb DATE -Date mise en garantie

Table référentiel bon du trésor

Attributs Type Commentaires


Code isin Code isin Clé primaire
Lib VARCHAR Libellé du bon du trésor
Date_ech DATE Date d’échéance du bon du
trésor
Unité VARCHAR Exprimé en général en millions
de dinars
Taux nominal NUMBER Taux d’intérêt défini au
moment de la création de
l’emprunt
Categ VARCHAR Long terme/court terme

Table référentiel client

Attributs Type Commentaires


Identifiant NUMBER Clé primaire
Rais soc VARCHAR Raison social

Table utilisateurs

Attributs Type Commentaires


Code user NUMBER Clé primaire
Nom_prenom VARCHAR Nom et prénom
Login VARCHAR
Motdepasse VARCHAR
Profil VARCHAR Administrateur/Utilisateur
simple

Page 126
Chapitre IV : Implémentation

Table OpérationRefinancement

Attributs Type Commentaires


Code-Oper VARCHAR Clé primaire
Date-Oper VARCHAR Date de l’opération
Donneur VARCHAR Banque centrale de Tunisie
Receveur VARCHAR -Désigne la banque à qui la
banque centrale va accorder un
crédit.
Montant NUMBER Montant de l’opération
Taux NUMBER
Durée NUMBER Durée de l’opération de
refinancement
Date-Ech DATE Date échéance de l’opération

Table référentiel Banques


Attributs Type Commentaires
BQ VARCHAR Clé primaire
Libellé VARCHAR Libellé de la banque
Abréviation VARCHAR Abréviation de la banque
Adresse VARCHAR Adresse de la banque
FAX NUMBER Fax de la banque
Téléphone NUMBER Numéro de téléphone de la
banque

3. Diagramme de déploiement
Les diagrammes de déploiement sont utilisés pour représenter l’architecture physique
d’un système. Ils montrent la distribution des composants logiciels sur la base d’unités
d’exécution (les nœuds).
Les nœuds et les artéfacts représentent le concept principal du diagramme de déploiement.
Les diagrammes de déploiement peuvent être créés sur les packages, les classes, les
interfaces, les composants, les artéfacts et les nœuds. [8]
La figure 100 jointe ci-dessous représente le diagramme de déploiement :

Page 127
Chapitre IV : Implémentation

Figure 100 Diagramme de déploiement

3. Développement de l’application
Nous dévoilons dans cette partie les principaux logiciels que nous avons utilisés :
 Système de gestion de base de données relationnelle ORACLE
 Outil de développement Oracle Developer Forms
 Outil de conception Power AMC
 Outil d’administration TOAD
 Système d’exploitation Windows XP Professionnel
 Système d’exploitation LINUX pour le serveur des données et le serveur
d’application
3.1. Système de gestion de bases de données relationnelle ORACLE :

Le système de gestion de base de données relationnelle (SGBDR) est un logiciel


système de stockage et de partage des informations décomposées et organisées dans
des matrices appelées relations ou tables conformément au modèle de données relationnel. Le
contenu de la base de données peut ainsi être synthétisé par des opérations d'algèbre
relationnelle telles que l'intersection, la jointure et le produit cartésien. Un SGBDR permet
d'inscrire, de modifier, de trier, de retrouver, de transformer ou d'imprimer les informations
de la base de données. Il éviter la perte des informations due à des pannes. [9]

Page 128
Chapitre IV : Implémentation

3.2. Outil de développement Oracle Developer Forms

Oracle Forms est un générateur d’applications transactionnelles basé sur le langage


PL/SQL. Il permet de construire des applications intermédiaires complexes et portables d’une
interface graphique à une autre.
Oracle Forms se compose de 3 outils :
 Forms Designer qui permet de crée et de modifier les types de modules
telles que les formulaires, les menus et les bibliothèques.
 Forms generator
 Forms runtime
3.3. Outil d’administration TOAD
Toad (Tool for Oracle Application Developers) est un logiciel de la société Quest
Software qui permet de consulter et d'administrer une base de données. Il est utilisé en
particulier par les développeurs Oracle et les administrateurs de bases de données.

Principe de fonctionnement :
Toad est un client qui fonctionne sur les plateformes windows 32-bits (OS Windows
2000, XP, Vista, 7). Il permet de gérer les dictionnaires de données, les tables, les index, etc...
Il permet d'accéder aux bases Oracle, PostgreSQL, MySQL, SQL Server, et DB2. Un plugin
pour Eclipse existe aussi.
Il existe un projet Open source indépendant de la plateforme, TOra, qui offre des
fonctions de base de Toad. [10]

Figure 101 Toad For Oracle


Page 129
Chapitre IV : Implémentation

4. Les interfaces de développement


4.1. Interface de l’Authentification
La première interface qu’on aborde est celle de l’authentification vu que c’est la
première étape à effectuer avant de passer au menu.

La figure 102 jointe ci-dessous représente l’interface de l’authentification :

Figure 102 Interface de l'authentification

4.2. Interface du Menu Principal


Après avoir été authentifié, l’utilisateur se retrouve face au menu principal. On peut y
distinguer des listes regroupées selon plusieurs critères : une liste pour la gestion du
portefeuille de crédits, une liste pour la gestion de l’encours bon du trésor, une liste pour la
gestion des garanties crédits, une liste pour la gestion des garanties bons du trésor, une liste
pour les référentiels et une liste pour la gestion des utilisateurs mais qui reste grisé si
l’utilisateur n’est pas un administrateur.
La figure 103 jointe ci-dessous représente l’interface du menu principal :

Page 130
Chapitre IV : Implémentation

Figure 103 Interface du menu principal

4.3. Interface de la Gestion du portefeuille de crédits


On distingue trois interfaces, une pour l’ajout d’un crédit, une autre pour la
consultation d’un crédit qui permet aussi de modifier et supprimer un crédit et une dernière
pour la sélection des tombées.
La figure 104 jointe ci-dessous représente l’interface de l’ajout d’un crédit au
portefeuille :

Figure 104 Interface "Ajouter crédit au portefeuille"

La figure 105 jointe ci-dessous représente l’interface de la consultation d’un crédit :

Page 131
Chapitre IV : Implémentation

Figure 105 Interface "Consulter un crédit du portefeuille"

La figure 106 jointe ci-dessous représente l’interface de sélection des tombées :

Figure 106 Interface de Sélection des tombées

4.4. Interface de la Gestion de l’encours bon du trésor


De même que la gestion du portefeuille de crédits, on a 3 interfaces : la première pour
ajouter un bon du trésor, la deuxième pour la consultation et mise à jour d’un bon du trésor et
la troisième pour vérifier la validité de la date d’échéance d’un bon du trésor.
La figure 107 jointe ci-dessous représente l’interface de l’ajout d’un bon du trésor
dans l’encours:

Page 132
Chapitre IV : Implémentation

Figure 107 Interface "Ajouter bon du trésor dans l'encours"

La figure 108 jointe ci-dessous représente l’interface de consultation d’un bon du trésor :

Figure 108 Interface "Consulter un bon du trésor de l'encours"

La figure 109 jointe ci-dessous représente l’interface de vérification de l’échéance d’un bon
du trésor :

Page 133
Chapitre IV : Implémentation

Figure 109 Interface "Vérifier échéance bon du trésor"

4.5.Interface de la gestion des garanties Crédits

L’interface est séparée en deux blocs : le premier a pour rôle d’afficher une opération
de refinancement et la deuxième permet d’ajouter, modifier ou supprimer une garantie.
La figure 110 jointe ci-dessous représente l’interface de gestion de garanties crédit:

Page 134
Chapitre IV : Implémentation

Figure 110 Interface "Gestion garanties crédits"

4.6.Interface de la Gestion des garanties bons du trésor


Deux principaux blocs sont affichés dans l’interface de gestion des garanties des bons
du trésor. La consultation d’une opération de refinancement permet de passer au bloc des
garanties.
La figure 111 jointe ci-dessous représente l’interface de gestion garanties bon du trésor :

Page 135
Chapitre IV : Implémentation

Figure 111 Interface "Gestion garanties bon du trésor"

4.7.Interfaces de la gestion du référentiel Banques :


On arbore dans la partie suivante les deux principales interfaces de la gestion du
référentiel banques
La figure 112 jointe ci-dessous représente l’interface de l’ajout d’une banque:

Page 136
Chapitre IV : Implémentation

Figure 112 Interface "Ajouter banque"

La figure 113 jointe ci-dessous représente l’interface de consultation d’une banque :

Figure 113 Interface "Consulter banque"

4.8.Interfaces de la gestion référentiel Bons du trésor


La gestion du référentiel des bons du trésor comprend deux interfaces qu’on présente
dans les figures suivantes
La figure 114 jointe ci-dessous représente l’interface de l’ajout d’un bon du trésor:

Page 137
Chapitre IV : Implémentation

Figure 114 Interface "Ajouter bon du trésor"

La figure 115 jointe ci-dessous représente l’interface de consultation d’un bon du trésor :

Figure 115 Interface "Consulter bon du trésor"

4.9.Interfaces de la gestion du Référentiel Clients


La gestion du référentiel des clients a besoin de deux interfaces.
La figure 116 jointe ci-dessous représente l’interface de l’ajout d’un client :

Page 138
Chapitre IV : Implémentation

Figure 116 Interface "Ajouter client"

La figure 117 jointe ci-dessous représente l’interface de consultation d’un client :

Figure 117 Interface "Consulter client"

4.10. Interfaces de gestion Référentiel Crédits


Tout comme les trois autres référentiels, la gestion du référentiel des crédits n’a besoin
que de deux interfaces comme indiqué dans les figures suivantes
La figure 118 jointe ci-dessous représente l’interface de l’authentification :

Page 139
Chapitre IV : Implémentation

Figure 118 Interface "Ajouter crédit"

La figure 119 jointe ci-dessous représente l’interface de consultation d’un crédit :

Figure 119 Interface "Consulter crédit"

4.11. Interfaces de gestion des utilisateurs :


La gestion des utilisateurs est gérée par l’administrateur. Deux possibilités s’offrent à
ce dernier. Il peut ajouter un nouvel utilisateur et lui attribuer un profil afin qu’il n’ait pas
accès à certaines parties de l’application. L’autre possibilité consiste à consulter un utilisateur,
il peut par la suite modifier certaines informations ou bien supprimer un utilisateur.
La figure 120 jointe ci-dessous représente l’interface de l’ajout d’un utilisateur :

Page 140
Chapitre IV : Implémentation

Figure 120 Interface "Ajouter Utilisateur"

La figure 121 jointe ci-dessous représente l’interface de l’authentification :

Figure 121 Interface "Consulter Utilisateur"

5. Conclusion
Ce chapitre annonce la fin du cycle de développement. Malgré les contraintes
affrontées, nous avons pu réaliser une application exécutable qui assure les fonctionnalités des
cas d'utilisation définis dans les phases précédentes et prêt à transiter vers les utilisateurs de
manière itérative et incrémentale.

Page 141
Conclusion Générale

Conclusion Générale
Ce stage constitue une initiation et une prise de contact avec la vie professionnelle,
nous avons été appelées à mettre en place une application de gestion et de suivi de
contreparties de refinancement.
Notre passage par la banque centrale de Tunisie a été fructueux et très enrichissant.
En effet, ce stage nous a donné l’opportunité de mettre en pratique nos
connaissances acquises durant notre cursus universitaire, de nous familiariser avec d’autres
outils et de profiter de l’environnement professionnel et des compétences de cette
organisation par l’échange d’idées et d’informations.
Le langage de modélisation « UML »utilisé nous a permis de bénéficier de ces
niveaux de conception pour une meilleure compréhension du domaine étudié.
L’implémentation du système sous « ORACLE »s’est avérée profitable par l’usage de
nouvelles évolutions des outils de développement tels que Forms Builder et le langage
PL/SQL ainsi que pour l’exploitation des notions de réutilisation qu’ils offrent.
Le travail effectué a fait l’objet d’une analyse détaillée des besoins des utilisateurs,
de la conception et de l’élaboration d’un logiciel informatique qui prend encore plus de
fiabilité et d’efficacité.
On peut parvenir à une évolution dans le futur compte tenu du fait qu’aucun produit
n’est totalement parfait et que toute conception peut s’enrichir et évoluer. Nous proposons
que la déclaration des lignes de bon du Trésors et les encours relatifs à ces lignes sera
transmise via le système d’échange de données (SED), ce qui permet le traitement
automatique de ces déclarations et qui entraine par la suite la réduction du temps de traitement
et d’éviter les erreurs détectés lors de prise en charge manuel de ces déclarations.

Page 142
Webographie

Webographie
[1], [2] :
http://www.bct.gov.tn/ consulté le (13/02/2014)
[4] :
http://www.ouestdecision.fr/contenu/les_editeurs/fiches/fiche-produit-power-amc.htm
consulté le (20/02/2014)
[5] :
http://fr.wikipedia.org/wiki/Architecture_trois_tiers consulté le (28/02/2014)

[6] :
http://www.memoireonline.com/07/08/1225/mise-en-place-systeme-information-oracle-
architecture-trois-tiers.html consulté le (28/02/2014)

[7] :
http://uml.developpez.com/faq/?page=Cas-d-utilisation#Qu-est-ce-qu-un-acteur consulté le
(01/03/2014)
[8] :
http://support.objecteering.com/objecteering6.1/help/fr/objecteering_uml_modeler/diagrams/d
eployment_diagrams.htm consulté le (20/03/2014)

[9] :
http://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es_relationnelle consulté le (02/04/2014)
[10] :
http://fr.wikipedia.org/wiki/Toad_(logiciel) consulté le (10/04/2014)

Page 143
Bibliographie

Bibliographie
[3] : Les cahiers du programmeur uml2 - modéliser une application web –
Auteur(s) : Pascal Roques
Editeur(s) : Eyrolles
Collection : Les cahiers du programmeur
Nombre de pages : 246 pages
Date de parution : 02/10/2008 (4e édition)
EAN13 : 9782212123890

Page 144