Ce document présente le projet de fin d'études de Khadija Bouguerra et Lina Esseghaier, visant à concevoir et réaliser une application de gestion et suivi des contreparties de refinancement pour l'obtention d'une licence fondamentale en informatique de gestion. Il inclut des remerciements aux encadreurs et une structure détaillée du travail comprenant plusieurs chapitres sur le contexte, la spécification des exigences, l'analyse, la conception, et l'implémentation. Le projet se déroule dans un environnement de collaboration avec la Banque Centrale de Tunisie.

1. Université de Tunis
Institut supérieur de Gestion
Projet de fin d’études :
Pour l’obtention de la licence fondamentale en Informatique de Gestion
Travail proposé et réalisé en collaboration avec :
Encadré par :
Ahmed Badreddine
Chokri Kharrat
Réalisé par :
Khadija Bouguerra
Lina Esseghaier
Année universitaire : 2013/2014
Conception et réalisation d’une application de
gestion et suivi des contreparties de refinancement

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

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

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

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

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

7. 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édits86
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ésor90
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

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

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

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

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

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

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

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

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

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

17. Introduction
Page 1
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.

18. Introduction
Page 2
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.

19. Chapitre I : Contexte Général
Page 3
Chapitre I :
Contexte
Général

20. Chapitre I : Contexte Général
Page 4
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.

21. Chapitre I : Contexte Général
Page 5
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).

22. Chapitre I : Contexte Général
Page 6
- 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

23. Chapitre I : Contexte Général
Page 7
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.

24. Chapitre I : Contexte Général
Page 8
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

25. Chapitre I : Contexte Général
Page 9
 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.

26. Chapitre I : Contexte Général
Page 10
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 :

27. Chapitre I : Contexte Général
Page 11
 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.

28. Chapitre I : Contexte Général
Page 12
- 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.

29. Chapitre I : Contexte Général
Page 13
- 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.

30. Chapitre I : Contexte Général
Page 14
 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.

31. Chapitre I : Contexte Général
Page 15
 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.

32. Chapitre I : Contexte Général
Page 16
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
Besoins
fonctionnels
Diagramme
de cas
d'utilisation
initial
Scénario
détaillé de
chaque cas
d'utilisation
Diagramme
séquence
système
Diagramme
de classe
participante
Diagramme
de séquence
détaillé
Diagramme
de classe
global

33. Chapitre I : Contexte Général
Page 17
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) ;

34. Chapitre I : Contexte Général
Page 18
 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.

35. Chapitre II : Spécification des Exigences
Page 19
Chapitre II :
Spécification
Des
Exigences

36. Chapitre II : Spécification des Exigences
Page 20
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.

37. Chapitre II : Spécification des Exigences
Page 21
Figure 5 Diagramme de cas d’utilisation initial
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<< include>>
<< include>>
<<Utilisateur BCT>>
Gèrer portefeuille crédit
Gèrer encoursbon du trésor
Gèrer garantiescrédits
Gèrer garantiesbonsdu trésor
s'authentifier
Consulter opération refinancement
Gèrer référentiel clients
Gèrer référentiel crédits
<<Administrateur>>
Gèrer Utilisateurs
Gèrer référentiel banques

38. Chapitre II : Spécification des Exigences
Page 22
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

39. Chapitre II : Spécification des Exigences
Page 23
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
principal
-L’utilisateur introduit le login et le mot de passe pour s’identifier
-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
<<Utilisateur BCT>>
S'authentifier
Acteur_2

40. Chapitre II : Spécification des Exigences
Page 24
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 :
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:
Figure 8 Raffinement du Cas d’utilisation « Gérer portefeuille de crédits »
Authentification
3:Afficher le menu principal()
2:Afficher("Veuillez réessayer à nouveau")
1:Saisir(login,mot_de_passe)
<<Utilisateur BCT>>
<<system>>
Refinancement
Erreur
Succès
alt
3:Afficher le menu principal()
2:Afficher("Veuillez réessayer à nouveau")
1:Saisir(login,mot_de_passe)
<<extend>>
<<extend>>
<<Utilisateur BCT>>
Gérer portefeuille crédit
Consulter crédit Ajouter crédit
Modifier crédit
Selectionner les tombées
Supprimer crédit

41. Chapitre II : Spécification des Exigences
Page 25
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:
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
Ajouter crédit
3:Afficher (erreur)
2:Afficher(Ajout accepté)
1:saisir details crédit ( )
<<Utilisateur BCT>>
<<System>>
Refinancement
valides
invalides
alt
3:Afficher (erreur)
2:Afficher(Ajout accepté)
1:saisir details crédit ( )

42. Chapitre II : Spécification des Exigences
Page 26
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
d’utilisation
Consulter un crédit du portefeuille
Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario
principal
-L’utilisateur BCT saisit les critères de recherche d’un crédit
-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 :

43. Chapitre II : Spécification des Exigences
Page 27
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
consulter portefeuille crédit
4:Afficher (erreur)
3:Afficher (crédit inexistant)
2:Afficher_details crédit ( )
1:Saisir (critères crédit)
<<Utilisateur BCT>>
<<System>>
Refinancement
critères valides
critères invalides
alt
crédit existant
crédit inexistant
alt
4:Afficher (erreur)
3:Afficher (crédit inexistant)
2:Afficher_details crédit ( )
1:Saisir (critères crédit)

44. Chapitre II : Spécification des Exigences
Page 28
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:
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
d’utilisation
Sélectionner des tombées
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 une date.
-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
sequence modifier portefeuille crédit
3:Afficher (erreur )
2:Afficher (modification effectuée )
1:Saisir (modifications)
<<Utilisateur BCT>>
<<System>>
Refinancement
succès
erreur
alt
3:Afficher (erreur )
2:Afficher (modification effectuée )
1:Saisir (modifications)

45. Chapitre II : Spécification des Exigences
Page 29
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:
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
selection des tombées
3:Afficher (aucun crédit à supprimer)
2:Afficher (suppression effectuée)
1:Saisir (date système)
<<System>>
Refinancement
<<Utilisateur BCT>>
date crédit <date systeme
date crédit > date systeme
alt
3:Afficher (aucun crédit à supprimer)
2:Afficher (suppression effectuée)
1:Saisir (date système)

46. Chapitre II : Spécification des Exigences
Page 30
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 :
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:
Sequence supprimer crédit
1:click_bt supprimer crédit()
2:Afficher(suppression effectuée)
3:Afficher (erreur)
<<System>>
Refinancement
<<Utilisateur BCT>>
succès
erreur
alt
1:click_bt supprimer crédit()
2:Afficher(suppression effectuée)
3:Afficher (erreur)

47. Chapitre II : Spécification des Exigences
Page 31
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
d’utilisation
Ajouter un bon du trésor au portefeuille
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition L’apport d’un bon du trésor effectué
Scénario
principal
-L’utilisateur BCT saisit le bon du trésor envoyé par STICODVAM
-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
<<extend>>
<<extend>>
<<Utilisateur BCT>>
Gérer encours bons du trésor
Consulter bon du trésor Ajouter bon du trésor
Modifier bon du
trésor
Verifier échéance bon du trésor
Supprimer bon du
trésor

48. Chapitre II : Spécification des Exigences
Page 32
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:
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
Ajouter bon trésor
1:saisir (details bon trésor)
2:Afficher (ajout accepté)
3:Afficher (erreur)
<<Utilisateur BCT>>
<<System>>
Refinancement
valides
invalides
alt
1:saisir (details bon trésor)
2:Afficher (ajout accepté)
3:Afficher (erreur)
Figure 15 Diagramme séquence système de l'ajout d'un bon du trésor

49. Chapitre II : Spécification des Exigences
Page 33
Cas
d’utilisation
Consulter encours 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 saisit les critères de recherche du bon du trésor à consulter
-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:

50. Chapitre II : Spécification des Exigences
Page 34
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
consulter encours bon trésor
1:Saisir (critères bon trésor )
2:Afficher_details bon trésor ( )
3: Afficher (bon trésor inexistant)
4:Afficher (erreur)
<<System>>
Refinancement
<<Utilisateur BCT>>
critères valides
critères invalides
alt
bon trésor existant
bon trésor inexistant
alt
1:Saisir (critères bon trésor )
2:Afficher_details bon trésor ( )
3: Afficher (bon trésor inexistant)
4:Afficher (erreur)
Figure 16 Diagramme séquence système de la consultation d'un bon du
trésor

51. Chapitre II : Spécification des Exigences
Page 35
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 :
Figure 17 Diagramme séquence système de suppression d'un bon du trésor
Sequence supprimer encours bon trésor
1:click_bt supprimer bon trésor()
2:Afficher (suppression effectuée)
3:Afficher (erreur)
<<System>>
Refinancement
<<Utilisateur BCT>>
succès
erreur
alt
1:click_bt supprimer bon trésor()
2:Afficher (suppression effectuée)
3:Afficher (erreur)

52. Chapitre II : Spécification des Exigences
Page 36
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
1:Saisir (modifications)
2:Afficher (modification effectuée)
3:Afficher (erreur)
<<Utilisateur BCT>>
<<System>>
Refinancement
succès
erreur
alt
1:Saisir (modifications)
2:Afficher (modification effectuée)
3:Afficher (erreur)
Figure 18 Diagramme séquence système de modification d'un bon du trésor

53. Chapitre II : Spécification des Exigences
Page 37
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
d’utilisation
Vérifier échéance bon du trésor
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
principal
-L’utilisateur BCT saisit une date
-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 :

54. Chapitre II : Spécification des Exigences
Page 38
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:
verification echeance bon trésor
1:Saisir (date règlement operation)
2:Afficher (date échéance atteinte)
3:Afficher ( date échéance n'est pas
encore atteinte)
<<System>>
Refinancement
<<Utilisateur BCT>>
date crédit <date systeme
date crédit > date systeme
alt
1:Saisir (date règlement operation)
2:Afficher (date échéance atteinte)
3:Afficher ( date échéance n'est pas
encore atteinte)

55. Chapitre II : Spécification des Exigences
Page 39
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 :
<<extend>> <<extend>>
<<Utilisateur BCT>>
Gérer garantie crédits
Consulter garantie crédits
Ajouter garantie crédits
Modifier garantie crédits Supprimer garantie crédits
Consulter operation de
refinancement

56. Chapitre II : Spécification des Exigences
Page 40
Cas
d’utilisation
Ajouter garantie crédit
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout effectué
Scénario
principal
-L’utilisateur BCT saisit la date de l’opération de refinancement à consulter.
-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:

57. Chapitre II : Spécification des Exigences
Page 41
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
Ajouter garantie crédit
5:Afficher(erreur)
4:Afficher(Ajout effectué)
3:Sélectionner(crédit)
2:Afficher(opération de refinancement)
1:Saisir(date opération)
<<Utilisateur BCT>>
<<system>>
Refinancement
Valide
Invalide
alt
5:Afficher(erreur)
4:Afficher(Ajout effectué)
3:Sélectionner(crédit)
2:Afficher(opération de refinancement)
1:Saisir(date opération)
Figure 21 Diagramme séquence système de l'ajout d'une garantie crédit

58. Chapitre II : Spécification des Exigences
Page 42
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 :
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
d’utilisation
Consulter garantie crédit
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario
principal
-L’utilisateur BCT introduit les critères de recherche de garantie crédit à consulter
-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
Modifier garantie crédit
1:Saisir (modifications)
2:Afficher(modification effectuée)
3:Afficher (erreur )
<<Utilisateur BCT>>
<<System>>
Refinancement
succès
erreur
alt
1:Saisir (modifications)
2:Afficher(modification effectuée)
3:Afficher (erreur )
Figure 22 Diagramme séquence système de modification d'une garantie crédit

59. Chapitre II : Spécification des Exigences
Page 43
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:
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
consulter garantie crédit
4:Afficher (erreur)
3:Afficher( Garantie crédit inexistante)
2:Afficher_details garantie crédit ( )
1:Saisir (critères garantie crédit )
<<System>>
Refinancement
<<Utilisateur BCT>>
critères valides
critères invalides
alt
garantie crédit existante
garantie crédit inexistante
alt
4:Afficher (erreur)
3:Afficher( Garantie crédit inexistante)
2:Afficher_details garantie crédit ( )
1:Saisir (critères garantie crédit )
Figure 23 Diagramme séquence système de consultation d'une garantie crédit

60. Chapitre II : Spécification des Exigences
Page 44
Cas
d’utilisation
Supprimer garantie crédit
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Table « garanties crédits » consultée
Post condition Consultation effectuée
Scénario
principal
-L’utilisateur BCT clique sur le bouton « Supprimer »
-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 :
Figure 24 Diagramme séquence système de suppression d'une garantie crédit
Sequence supprimer garantie crédit
1:click_bt supprimer garantie crédit ( )
2:Afficher (suppression effectuée)
3:Afficher (erreur)
<<System>>
Refinancement
<<Utilisateur BCT>>
succès
erreur
alt
1:click_bt supprimer garantie crédit ( )
2:Afficher (suppression effectuée)
3:Afficher (erreur)

61. Chapitre II : Spécification des Exigences
Page 45
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
d’utilisation
Consulter opération de refinancement
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario
principal
L’utilisateur BCT introduit les critères de recherche de l’opération de
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 :

62. Chapitre II : Spécification des Exigences
Page 46
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:
Consulter operation refinancement
1:Saisir ( critères operation )
2:Afficher _details operation de
refinancement ( )
3:Afficher(operation de refinancement
inexistante)
4:Afficher (erreur)
<<System>>
Refinancement
<<Utilisateur BCT>>
critères valides
critères invalides
alt
operation existante
operation inexistante
alt
1:Saisir ( critères operation )
2:Afficher _details operation de
refinancement ( )
3:Afficher(operation de refinancement
inexistante)
4:Afficher (erreur)

63. Chapitre II : Spécification des Exigences
Page 47
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 :
<<extend>> <<extend>>
<<Utilisateur BCT>>
Gérer garantie bons du trésor
Consulter garantie bons du trésor Ajouter garantie bons du trésor
Modifier garantie bons du trésor
Supprimer garantie bons du trésor
Consulter operation de
refinancement
Figure 26 Raffinement du cas "Gestion garanties bon du trésor"

64. Chapitre II : Spécification des Exigences
Page 48
Cas
d’utilisation
Ajouter garantie bon trésor
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout effectué
Scénario
principal
-L’utilisateur BCT saisit la date de l’opération de refinancement à consulter.
-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 :

65. Chapitre II : Spécification des Exigences
Page 49
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
Ajouter garantie bon du trésor
1:Saisir(date opération)
2:Afficher(opération de refinancement)
3:Sélectionner(bon du trésor)
4:Afficher(Ajout effectué)
5:Afficher(erreur)
<<Utilisateur BCT>>
<<system>>
Refinancement
Valide
Invalide
alt
1:Saisir(date opération)
2:Afficher(opération de refinancement)
3:Sélectionner(bon du trésor)
4:Afficher(Ajout effectué)
5:Afficher(erreur)

66. Chapitre II : Spécification des Exigences
Page 50
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:
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 :
Sequence modifier garantie bon trésor
3:Afficher (erreur)
2:Afficher (modification effectuée)
1:Saisir (modifications)
<<Utilisateur BCT>>
<<System>>
Refinancement
succès
erreur
alt
3:Afficher (erreur)
2:Afficher (modification effectuée)
1:Saisir (modifications)

67. Chapitre II : Spécification des Exigences
Page 51
Cas
d’utilisation
Consulter 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 introduit les critères de recherche d’une garantie bon du trésor.
-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:

68. Chapitre II : Spécification des Exigences
Page 52
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
sequence consulter garantie bon trésor
1:Saisir (critères garantie bon trésor )
2:Afficher details garantie bon trésor ( )
3: Afficher (Garantie bon trésort
inexistante )
4:Afficher (erreur )
<<System>>
Refinancement
<<Utilisateur BCT>>
critères valides
critères invalides
alt
garantie bon trésor existante
garantie bon trésor inexistante
alt
1:Saisir (critères garantie bon trésor )
2:Afficher details garantie bon trésor ( )
3: Afficher (Garantie bon trésort
inexistante )
4:Afficher (erreur )

69. Chapitre II : Spécification des Exigences
Page 53
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:
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 :
Sequence supprimer garantie bon trésor
3:Afficher (erreur)
2:Afficher(suppression effectuée)
1:click_bt supprimer garantie bon trésor()
<<System>>
Refinancement
<<Utilisateur BCT>>
succès
erreur
alt
3:Afficher (erreur)
2:Afficher(suppression effectuée)
1:click_bt supprimer garantie bon trésor()

70. Chapitre II : Spécification des Exigences
Page 54
Cas
d’utilisation
Consulter opération de refinancement
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario
principal
-L’utilisateur BCT introduit les critères de recherche de l’opération de
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:

71. Chapitre II : Spécification des Exigences
Page 55
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:
Consulter operation refinancement
1:Saisir ( critères operation )
2:Afficher _details operation de
refinancement ( )
3:Afficher(operation de refinancement
inexistante)
4:Afficher (erreur)
<<System>>
Refinancement
<<Utilisateur BCT>>
critères valides
critères invalides
alt
operation existante
operation inexistante
alt
1:Saisir ( critères operation )
2:Afficher _details operation de
refinancement ( )
3:Afficher(operation de refinancement
inexistante)
4:Afficher (erreur)

72. Chapitre II : Spécification des Exigences
Page 56
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:
<<extend>>
<<Utiisateur BCT>>
Gèrer Référentiel Crédits
Consulter Crédit Ajouter crédit
Modifier crédit

73. Chapitre II : Spécification des Exigences
Page 57
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
principal
-L’utilisateur BCT saisit le code du crédit à 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 « 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
Sequence ajouter référentiel crédit
1:saisir (details référentiel crédit)
2:Afficher (ajout accepté)
3:Afficher(ajout non effectué)
<<Utilisateur BCT>>
<<System>>
Refinancement
valides
invalides
alt
1:saisir (details référentiel crédit)
2:Afficher (ajout accepté)
3:Afficher(ajout non effectué)

74. Chapitre II : Spécification des Exigences
Page 58
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:
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 :
Sequence consulter référentiel crédit
1:Saisir (critères référentiel crédit )
2:Afficher_details référentiel crédit()
3:Afficher( Référentiel crédit inexistant )
4:Afficher (erreur )
<<System>>
Refinancement
<<Utilisateur BCT>>
critères valides
critères invalides
alt
référentiel crédit existant
référentiel crédit inexistant
alt
1:Saisir (critères référentiel crédit )
2:Afficher_details référentiel crédit()
3:Afficher( Référentiel crédit inexistant )
4:Afficher (erreur )

75. Chapitre II : Spécification des Exigences
Page 59
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:
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:
sequence modifier référentiel crédit
3:Afficher (erreur)
2:Afficher (Modification effectuée)
1:Saisir (modifications)
<<Utilisateur BCT>>
<<System>>
Refinancement
succès
erreur
alt
3:Afficher (erreur)
2:Afficher (Modification effectuée)
1:Saisir (modifications)

76. Chapitre II : Spécification des Exigences
Page 60
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
d’utilisation
Ajouter référentiel bon du trésor
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout du bon du trésor effectué
Scénario
principal
-L’utilisateur BCT saisit les informations
-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
<<extend>>
<<Utilisateur BCT>>
Gèrer Référentiel Bon du trésor
Consulter bon du trésor Ajouter bon du trésor
Modifier Bon du trésor

77. Chapitre II : Spécification des Exigences
Page 61
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:
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
Sequence ajouter référentiel bon trésor
3:Afficher(erreur)
2:Afficher (ajout accepté )
1:saisir (details référentiel bon trésor )
<<Utilisateur BCT>>
<<System>>
Refinancement
valides
invalides
alt
3:Afficher(erreur)
2:Afficher (ajout accepté )
1:saisir (details référentiel bon trésor )

78. Chapitre II : Spécification des Exigences
Page 62
²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:
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 :
Sequence consulter référentiel bon trésor
4:Afficher (erreur )
3: Afficher (référentiel bon trésort
inexistant )
2:Afficher_ details référentiel bon trésor
()
1:Saisir (critères référentiel bon trésor )
<<System>>
Refinancement
<<Utilisateur BCT>>
critères valides
critères invalides
alt
référentiel bon trésor existant
référentiel bon trésor inexistant
alt
4:Afficher (erreur )
3: Afficher (référentiel bon trésort
inexistant )
2:Afficher_ details référentiel bon trésor
()
1:Saisir (critères référentiel bon trésor )

79. Chapitre II : Spécification des Exigences
Page 63
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:
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:
Sequence modifier référentiel bon trésor
1:Saisir (modifications)
2:Afficher (modification effectuée)
3:Afficher (erreur )
<<Utilisateur BCT>>
<<System>>
Refinancement
succès
erreur
alt
1:Saisir (modifications)
2:Afficher (modification effectuée)
3:Afficher (erreur )

80. Chapitre II : Spécification des Exigences
Page 64
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
d’utilisation
Ajouter référentiel client
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout de 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 -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
<<extend>>
<<Utiisateur BCT>>
Gèrer Référentiel Clients
Consulter Client Ajouter client
Modifier client

81. Chapitre II : Spécification des Exigences
Page 65
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:
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:
Sequence ajouter référentiel client
1:saisir (details référentiel client)
2:Afficher (ajout accepté )
3:Afficher(erreur )
<<Utilisateur BCT>>
<<System>>
Refinancement
valides
invalides
alt
1:saisir (details référentiel client)
2:Afficher (ajout accepté )
3:Afficher(erreur )

82. Chapitre II : Spécification des Exigences
Page 66
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
Sequence consulter référentiel client
1:Saisir (critères référentiel client)
2:Afficher_details référentiel client()
3: Afficher (référentiel client
inexistant )
4:Afficher (erreur )
<<System>>
Refinancement
<<Utilisateur BCT>>
critères valides
critères invalides
alt
référentiel client existant
référentiel client inexistant
alt
1:Saisir (critères référentiel client)
2:Afficher_details référentiel client()
3: Afficher (référentiel client
inexistant )
4:Afficher (erreur )

83. Chapitre II : Spécification des Exigences
Page 67
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:
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:
Sequence modifier référentiel client
3:Afficher (erreur )
2:Afficher (modification effectuée)
1:Saisir (modifications)
<<Utilisateur BCT>>
<<System>>
Refinancement
succès
erreur
alt
3:Afficher (erreur )
2:Afficher (modification effectuée)
1:Saisir (modifications)

84. Chapitre II : Spécification des Exigences
Page 68
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
d’utilisation
Ajouter référentiel banque
Acteur Utilisateur BCT
Pré condition Utilisateur BCT identifié et autorisé
Post condition Ajout de banque effectué
Scénario
principal
-L’utilisateur BCT saisit les informations
-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
<<extend>>
<<Utiisateur BCT>>
Gèrer Référentiel Banques
Consulter banque Ajouter banque
Modifier banque

85. Chapitre II : Spécification des Exigences
Page 69
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:
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
Sequence ajouter référentiel banque
3:Afficher (erreur)
2:Afficher (ajout accepté)
1:saisir (details référentiel banque)
<<Utilisateur BCT>>
<<System>>
Refinancement
valides
invalides
alt
3:Afficher (erreur)
2:Afficher (ajout accepté)
1:saisir (details référentiel banque)

86. Chapitre II : Spécification des Exigences
Page 70
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:
Figure 46 Diagramme séquence système Consulter banque
Sequence consulter référentiel banque
4:Afficher (erreur )
3: Afficher (référentiel banque
inexistant)
2:Afficher_details référentiel banque()
1:Saisir (critères référentiel banque)
<<System>>
Refinancement
<<Utilisateur BCT>>
critères valides
critères invalides
alt
référentiel banque existant
référentiel banque inexistant
alt
4:Afficher (erreur )
3: Afficher (référentiel banque
inexistant)
2:Afficher_details référentiel banque()
1:Saisir (critères référentiel banque)

87. Chapitre II : Spécification des Exigences
Page 71
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:
Figure 47 Diagramme séquence système Modifier banque
Sequence modifier référentiel banque
1:Saisir (modifications)
2:Afficher (modification effectuée )
3:Afficher (erreur)
<<Utilisateur BCT>>
<<System>>
Refinancement
succès
erreur
alt
1:Saisir (modifications)
2:Afficher (modification effectuée )
3:Afficher (erreur)

88. Chapitre II : Spécification des Exigences
Page 72
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:
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
principal
-L’utilisateur BCT introduit le code de l’opération de refinancement
-Le système cherche dans la base de données
-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:
Cosulter Refinancement
<<utilisateur BCT>>

89. Chapitre II : Spécification des Exigences
Page 73
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:
Consulter operation refinancement
1:Saisir ( critères operation )
2:Afficher _details operation de
refinancement ( )
3:Afficher(operation de refinancement
inexistante)
4:Afficher (erreur)
<<System>>
Refinancement
<<Utilisateur BCT>>
critères valides
critères invalides
alt
operation existante
operation inexistante
alt
1:Saisir ( critères operation )
2:Afficher _details operation de
refinancement ( )
3:Afficher(operation de refinancement
inexistante)
4:Afficher (erreur)

90. Chapitre II : Spécification des Exigences
Page 74
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
d’utilisation
Ajouter utilisateur
Acteur Administrateur
Précondition Administrateur identifié
Post-condition Utilisateur ajouté
Scénario-
nominal
-L’administrateur saisit les informations concernant l’utilisateur -L’administrateur
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
<<extend>>
<<extend>>
<<Administrateur>>
Gérer utilisateurs
consulter utilisateurs ajouter utilisateurs
Modifier utilisateurs
Supprimer utilisateurs

91. Chapitre II : Spécification des Exigences
Page 75
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:
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:
Sequence ajouter utilisateur
3:Afficher (erreur )
2:Afficher( ajout accepté)
1:saisir (details utilisateur)
<<Administrateur BCT>>
<<System>>
Refinancement
valides
invalides
alt
3:Afficher (erreur )
2:Afficher( ajout accepté)
1:saisir (details utilisateur)

92. Chapitre II : Spécification des Exigences
Page 76
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
Sequence consulter utilisateur
4:Afficher (erreur )
3: Afficher (utilisateur inexistant)
2:Afficher _details utilisateur()
1:Saisir (critères utilisateur)
<<System>>
Refinancement
<<Administrateur BCT>>
critères valides
critères invalides
alt
utilisateur existant
utilisateur inexistant
alt
4:Afficher (erreur )
3: Afficher (utilisateur inexistant)
2:Afficher _details utilisateur()
1:Saisir (critères utilisateur)

93. Chapitre II : Spécification des Exigences
Page 77
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:
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:
Sequence modifier utilisateur
1:Saisir (modifications)
2:Afficher (modification effectuée)
3:Afficher(erreur )
<<Administrateur BCT>>
<<System>>
Refinancement
succès
erreur
alt
1:Saisir (modifications)
2:Afficher (modification effectuée)
3:Afficher(erreur )

94. Chapitre II : Spécification des Exigences
Page 78
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 :
Sequence supprimer utilisateur
1:click_bt supprimer utilisateur()
2:Afficher (suppression effectuée )
3:Afficher (erreur)
<<System>>
Refinancement
<<Administrateur BCT>>
succès
erreur
alt
1:click_bt supprimer utilisateur()
2:Afficher (suppression effectuée )
3:Afficher (erreur)

95. Chapitre II : Spécification des Exigences
Page 79
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 :
<<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 ()

96. Chapitre II : Spécification des Exigences
Page 80
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.

97. Chapitre III : Conception et Analyse
Page 81
Chapitre III
Conception et Analyse

98. Chapitre III : Conception et Analyse
Page 82
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.

99. Chapitre III : Conception et Analyse
Page 83
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

100. Chapitre III : Conception et Analyse
Page 84
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 :
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
Authentification
Afficher (champ incohérent, veuillez
réessayer à nouveau)
6:Afficher (erreur)
5:Afficher (connexion effectuée)
3:Consulter ( )
2:Prise en charge click ( )
1:Saisir(login, mot de passe)
Utilisateurs
Gest_Authentification
IU_Authentification
<<Utilsateur BCT>>
Saisie correcte
Saisie incorrecte
alt
Utilisateur trouvé
Utilisateur non trouvé
alt
Afficher (champ incohérent, veuillez
réessayer à nouveau)
6:Afficher (erreur)
5:Afficher (connexion effectuée)
3:Consulter ( )
2:Prise en charge click ( )
1:Saisir(login, mot de passe)

101. Chapitre III : Conception et Analyse
Page 85
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"

102. Chapitre III : Conception et Analyse
Page 86
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 :

103. Chapitre III : Conception et Analyse
Page 87
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:

104. Chapitre III : Conception et Analyse
Page 88
Figure 64 Diagramme séquence détaillé "Gestion portefeuille crédits"
Diag sequence portefeuille crédit
29:consulter ( )
28:consulter ( )
27:consulter ()
17:Supprimer ( )
15:Click_bt supprimer ( )
11:Mise à jour ( )
18:Supprimer ( )
33:Click_bt supprimer ( )
23:click bt ajouter ( )
20:Afficher ( erreur)
13:Afficher (erreur)
10:Prise en charge click ( )
9:click_bt modifier ( )
4:Click_bt consulter ( )
24:prise en charge click ( )
37:Afficher (suppression effectuée)
38:Afficher(pas de crédit à supprimer)
36:Supprimer ( )
35:Supprimer ( )
34:Prise en charge click ( )
32:Saisir(date)
31:Afficher(erreur)
30:Afficher (ajout effectué)
26:Ajouter ( )
25:Ajouter ( )
22:Saisir(critères crédit)
21:Afficher (crédit inexistant )
19:Afficher (suppression effectuée)
16:prise en charge click ( )
14:Afficher (modification effectuée)
12:Mise à jour ( )
8:Saisir (modifications)
7:Afficher _details crédit( )
6:Consulter ( )
5:Consulter( )
4:Prise en charge click ( )
3:Saisir( critères crédit)
2:Selectionner (opération)
1:Dérouler liste ( )
<<Utilisateur BCT>> IU_menu principal IU_consulter crédit IU_ajouter crédit IU_selection des tombées GEST_gestion portefeuille
crédit
portefeuille crédit encours crédit référentiel client référentiel banque référentiel crédit
[consulter]
opt
crédit existant
crédit inexistant
alt
erreur
succès
alt
[ajouter crédit]
opt
succès
erreur
alt
[selection des tombées]
opt
date crédit < date du jour
date crédit > date du jour
alt
[modifier]
opt
[supprimer]
opt
succès
erreur
alt
29:consulter ( )
28:consulter ( )
27:consulter ()
17:Supprimer ( )
15:Click_bt supprimer ( )
11:Mise à jour ( )
18:Supprimer ( )
33:Click_bt supprimer ( )
23:click bt ajouter ( )
20:Afficher ( erreur)
13:Afficher (erreur)
10:Prise en charge click ( )
9:click_bt modifier ( )
4:Click_bt consulter ( )
24:prise en charge click ( )
37:Afficher (suppression effectuée)
38:Afficher(pas de crédit à supprimer)
36:Supprimer ( )
35:Supprimer ( )
34:Prise en charge click ( )
32:Saisir(date)
31:Afficher(erreur)
30:Afficher (ajout effectué)
26:Ajouter ( )
25:Ajouter ( )
22:Saisir(critères crédit)
21:Afficher (crédit inexistant )
19:Afficher (suppression effectuée)
16:prise en charge click ( )
14:Afficher (modification effectuée)
12:Mise à jour ( )
8:Saisir (modifications)
7:Afficher _details crédit( )
6:Consulter ( )
5:Consulter( )
4:Prise en charge click ( )
3:Saisir( critères crédit)
2:Selectionner (opération)
1:Dérouler liste ( )

105. Chapitre III : Conception et Analyse
Page 89
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

106. Chapitre III : Conception et Analyse
Page 90
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 :

107. Chapitre III : Conception et Analyse
Page 91
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:

108. Chapitre III : Conception et Analyse
Page 92
Figure 69 Diagramme séquence detaillé "Gestion encours bon du trésor"
sequence encours bon du trésor
25:consulter( )
24:consulter ( )
1:Dérouler liste ( )
2:Selectionner (opération)
3:Saisir( critères bon du trésor)
5:Prise en charge click ( ) 6:Consulter ( )
7:Afficher _details bon du trésor ( )
8:Saisir (modifications)
11:Mise à jour ( )
13:Afficher (modification effectuée)
15:prise en charge click ( )
17:Afficher (suppression effectuée)
19:Afficher (bon du trésor inexistant )
20:Saisir(details bon du trésor) 23:Ajouter ( )
26:Afficher (ajout effectué)
27:Afficher(erreur)
28:Saisir(date du jour)
30:Prise en charge click ( )
31:Consulter( )
33:Afficher(bon du trésor n'a pas atteint l'
échéance)
32:Afficher (bon trésor a atteint
l'échéance)
22:prise en charge click ( )
4:Click_bt consulter ( )
9:click_bt modifier ( )
10:Prise en charge click ( )
12:Afficher (erreur)
18:Afficher ( erreur)
21:click bt ajouter ( )
29:Click_bt verifier( )
16:Supprimer ( )
14:Click_bt supprimer ( )
<<Utilisateur BCT>> IU_menu principal IU_consulter bon trésor IU_ajouter bon trésor IU_verifier échéance GEST_gestion encours
bon du trésor
encours bon du trésor référentiel banque référentiel bon du trésor
[consulter]
opt
bon trésor existant
bon trésor inexistant
alt
erreur
succès
alt
[ajouter bon trésor]
opt
succès
erreur
alt
[verifier échéance]
opt
date crédit < date du jour
date crédit > date du jour
alt
[modifier]
opt
[supprimer]
opt
succès
erreur
alt
25:consulter( )
24:consulter ( )
1:Dérouler liste ( )
2:Selectionner (opération)
3:Saisir( critères bon du trésor)
5:Prise en charge click ( ) 6:Consulter ( )
7:Afficher _details bon du trésor ( )
8:Saisir (modifications)
11:Mise à jour ( )
13:Afficher (modification effectuée)
15:prise en charge click ( )
17:Afficher (suppression effectuée)
19:Afficher (bon du trésor inexistant )
20:Saisir(details bon du trésor) 23:Ajouter ( )
26:Afficher (ajout effectué)
27:Afficher(erreur)
28:Saisir(date du jour)
30:Prise en charge click ( )
31:Consulter( )
33:Afficher(bon du trésor n'a pas atteint l'
échéance)
32:Afficher (bon trésor a atteint
l'échéance)
22:prise en charge click ( )
4:Click_bt consulter ( )
9:click_bt modifier ( )
10:Prise en charge click ( )
12:Afficher (erreur)
18:Afficher ( erreur)
21:click bt ajouter ( )
29:Click_bt verifier( )
16:Supprimer ( )
14:Click_bt supprimer ( )

109. Chapitre III : Conception et Analyse
Page 93
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"

110. Chapitre III : Conception et Analyse
Page 94
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"

111. Chapitre III : Conception et Analyse
Page 95
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:
Figure 72 Diagramme séquence détaillé "Gestion garantie crédits"
DiagrammeSequence garantie crédit
27:Afficher (erreur)
26:Afficher (succès)
21:Click_bt ajouter ( )
20:Saisir (details garantie crédit)
29:Click_bt consulter operation
refinancement( )
25:Ajouter ( )
24:Ajouter ( )
23:Ajouter ( )
18:Afficher (erreur)
12:Afficher (erreur)
9:Click_bt modifier ( )
4:Click_bt consulter ( )
22:Ajouter ( )
33:Afficher (erreur)
32:Afficher_details operation de
refinancement( )
30:Prise en charge click( )
19:Afficher ( garantie crédit inexistante)
17:Afficher (suppression effectuée)
15:Prise en charge click( )
14:Click_bt supprimer
13:Afficher( modification effectuée)
11:Mise à jour ( )
10:Prise en charge click ( )
8:Saisir (modifications)
7:Afficher_details garantie crédit ( )
6:Consulter ( )
5:Prise en charge click ( )
3:Saisir( critères garantie crédit)
2:Selectionner (opération)
1:Dérouler liste ( )
31:Consulter ( )
28:saisir (critères operation
refinancement)
16:Supprimer ( )
<<Utilisateur BCT>> IU_menu principal IU_consulter garantie
crédit
IU_consulter operation
refinancement
GEST_gestion garantie
crédit
encours crédit garantie crédit operation refinancement portefeuille crédit
[consulter]
opt
garantie crédit existante
garantie crédit inexistante
alt
erreur
succès
alt
[ajout garantie crédit]
opt
[consulter operation refinancement]
opt
succès
erreur
alt
[Modifier]
opt
[Supprimer]
opt
succès
erreur
alt
succès
erreur
alt
27:Afficher (erreur)
26:Afficher (succès)
21:Click_bt ajouter ( )
20:Saisir (details garantie crédit)
29:Click_bt consulter operation
refinancement( )
25:Ajouter ( )
24:Ajouter ( )
23:Ajouter ( )
18:Afficher (erreur)
12:Afficher (erreur)
9:Click_bt modifier ( )
4:Click_bt consulter ( )
22:Ajouter ( )
33:Afficher (erreur)
32:Afficher_details operation de
refinancement( )
30:Prise en charge click( )
19:Afficher ( garantie crédit inexistante)
17:Afficher (suppression effectuée)
15:Prise en charge click( )
14:Click_bt supprimer
13:Afficher( modification effectuée)
11:Mise à jour ( )
10:Prise en charge click ( )
8:Saisir (modifications)
7:Afficher_details garantie crédit ( )
6:Consulter ( )
5:Prise en charge click ( )
3:Saisir( critères garantie crédit)
2:Selectionner (opération)
1:Dérouler liste ( )
31:Consulter ( )
28:saisir (critères operation
refinancement)
16:Supprimer ( )

112. Chapitre III : Conception et Analyse
Page 96
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"

113. Chapitre III : Conception et Analyse
Page 97
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"

114. Chapitre III : Conception et Analyse
Page 98
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
Figure 75 Diagramme séquence détaillé "Gestion garanties Bon du trésor"
DiagrammeSequence garantie bon du trésor
26:Afficher (erreur)
25:Afficher (succès)
21:Clik bt ajouter ( )
20:Saisir (details garantie bon trésor)
28:Click_bt consulter operation
refinancement ( )
16:Supprimer ( )
27:saisir (critères operation
refinancement)
30:Consulter ( )
1:Dérouler liste ( )
2:Selectionner (opération)
3:Saisir( critères garantie bon du trésor)
5:Prise en charge click ( ) 6:Consulter ( )
7:Afficher_details garantie bon trésor ( )
8:Saisir (modifications)
10:Prise en charge click ( )
11:Mise à jour ( )
13:Afficher( modification effectuée)
14:Click_bt supprimer 15:Prise en charge click( )
17:Afficher (suppression effectuée)
19:Afficher ( garantie bon trésor
inexistante)
29:prise en charge click ( )
31:Afficher(details operation de
refinancement)
32:Afficher(erreur)
22:Ajouter ( )
4:Click_bt consulter ( )
9:Click_bt modifier ( )
12:Afficher (erreur)
18:Afficher (erreur)
23:Ajouter ( )
24:Ajouter ( )
<<Utilisateur BCT>> IU_menu principal IU_consulter garantie bon
trésor
IU_consulter operation
refinancement
GEST_gestion garantie
bon du trésor
encours bon du trésor garantie bon du trésor operation refinancement
[consulter]
opt
garantie bon trésor existante
garantie bon trésor inexistante
alt
erreur
succès
alt
[ajout garantie bon trésor]
opt
[consulter operation refinancement]
opt
succès
erreur
alt
[Modifier]
opt
[Supprimer]
opt
succès
erreur
alt
succès
erreur
alt
26:Afficher (erreur)
25:Afficher (succès)
21:Clik bt ajouter ( )
20:Saisir (details garantie bon trésor)
28:Click_bt consulter operation
refinancement ( )
16:Supprimer ( )
27:saisir (critères operation
refinancement)
30:Consulter ( )
1:Dérouler liste ( )
2:Selectionner (opération)
3:Saisir( critères garantie bon du trésor)
5:Prise en charge click ( ) 6:Consulter ( )
7:Afficher_details garantie bon trésor ( )
8:Saisir (modifications)
10:Prise en charge click ( )
11:Mise à jour ( )
13:Afficher( modification effectuée)
14:Click_bt supprimer 15:Prise en charge click( )
17:Afficher (suppression effectuée)
19:Afficher ( garantie bon trésor
inexistante)
29:prise en charge click ( )
31:Afficher(details operation de
refinancement)
32:Afficher(erreur)
22:Ajouter ( )
4:Click_bt consulter ( )
9:Click_bt modifier ( )
12:Afficher (erreur)
18:Afficher (erreur)
23:Ajouter ( )
24:Ajouter ( )

115. Chapitre III : Conception et Analyse
Page 99
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"

116. Chapitre III : Conception et Analyse
Page 100
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 :

117. Chapitre III : Conception et Analyse
Page 101
Figure 79 Diagramme séquence détaillé "Gestion référentiel banque"
DiagrammeSequence référentiel banque
1:Dérouler liste ( )
2:Selectionner (opération)
3:Saisir( critères banque)
5:Prise en charge click ( ) 6:Consulter ( )
7:Afficher _details banque ( )
8:Saisir (modifications)
11:Mise à jour ( )
13:Afficher (modification effectuée)
14:Afficher (banque inexistante)
15:Saisir(critères banque)
18:Ajouter ( )
19:Afficher (ajout effectué)
20:Afficher(erreur)
17:prise en charge click ( )
4:Click_bt consulter ( )
9:click_bt modifier ( )
10:Prise en charge click ( )
12:Afficher (erreur)
16:click bt ajouter ( )
<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel
banque
IU_ajouter banque GEST_gestion référentiel
banque
banque
[consulter]
opt
banque existante
banque inexistante
alt
erreur
succès
alt
[ajouter bon trésor]
opt
succès
erreur
alt
[modifier]
opt
1:Dérouler liste ( )
2:Selectionner (opération)
3:Saisir( critères banque)
5:Prise en charge click ( ) 6:Consulter ( )
7:Afficher _details banque ( )
8:Saisir (modifications)
11:Mise à jour ( )
13:Afficher (modification effectuée)
14:Afficher (banque inexistante)
15:Saisir(critères banque)
18:Ajouter ( )
19:Afficher (ajout effectué)
20:Afficher(erreur)
17:prise en charge click ( )
4:Click_bt consulter ( )
9:click_bt modifier ( )
10:Prise en charge click ( )
12:Afficher (erreur)
16:click bt ajouter ( )

118. Chapitre III : Conception et Analyse
Page 102
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"

119. Chapitre III : Conception et Analyse
Page 103
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

120. Chapitre III : Conception et Analyse
Page 104
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 :

121. Chapitre III : Conception et Analyse
Page 105
Figure 83 Diagramme séquence détaillé "Gestion référentiel bon du trésor"
DiagrammeSequence référentiel bon trésor
16:click bt ajouter ( )
12:Afficher (erreur)
10:Prise en charge click ( )
9:click_bt modifier ( )
4:Click_bt consulter ( )
17:prise en charge click ( )
20:Afficher(erreur)
19:Afficher (ajout effectué)
18:Ajouter ( )
15:Saisir(details bon du trésor)
14:Afficher (bon du trésor inexistant )
13:Afficher (modification effectuée)
11:Mise à jour ( )
8:Saisir (modifications)
7:Afficher _details bon du trésor ( )
6:Consulter ( )
5:Prise en charge click ( )
3:Saisir( critères bon du trésor)
2:Selectionner (opération)
1:Dérouler liste ( )
<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel
bon trésor
IU_ajouter bon trésor GEST_gestion référentiel
bon du trésor
bon du trésor
[consulter]
opt
bon trésor existant
bon trésor inexistant
alt
erreur
succès
alt
[ajouter bon trésor]
opt
succès
erreur
alt
[modifier]
opt
16:click bt ajouter ( )
12:Afficher (erreur)
10:Prise en charge click ( )
9:click_bt modifier ( )
4:Click_bt consulter ( )
17:prise en charge click ( )
20:Afficher(erreur)
19:Afficher (ajout effectué)
18:Ajouter ( )
15:Saisir(details bon du trésor)
14:Afficher (bon du trésor inexistant )
13:Afficher (modification effectuée)
11:Mise à jour ( )
8:Saisir (modifications)
7:Afficher _details bon du trésor ( )
6:Consulter ( )
5:Prise en charge click ( )
3:Saisir( critères bon du trésor)
2:Selectionner (opération)
1:Dérouler liste ( )

122. Chapitre III : Conception et Analyse
Page 106
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"

123. Chapitre III : Conception et Analyse
Page 107
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

124. Chapitre III : Conception et Analyse
Page 108
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 :

125. Chapitre III : Conception et Analyse
Page 109
Figure 87 Diagramme séquence détaillé "Gestion référentiel clients"
DiagrammeSequence référentiel client
16:click bt ajouter ( )
12:Afficher (erreur)
10:Prise en charge click ( )
9:click_bt modifier ( )
4:Click_bt consulter ( )
17:prise en charge click ( )
20:Afficher(erreur)
19:Afficher (ajout effectué)
18:Ajouter ( )
15:Saisir(details client)
14:Afficher (client inexistant )
13:Afficher (modification effectuée)
11:Mise à jour ( )
8:Saisir (modifications)
7:Afficher _details client ( )
6:Consulter ( )
5:Prise en charge click ( )
3:Saisir( critères client)
2:Selectionner (opération)
1:Dérouler liste ( )
<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel
client
IU_ajouter client GEST_gestion référentiel
client
client
[consulter]
opt
client existant
client inexistant
alt
erreur
succès
alt
[ajouter client]
opt
succès
erreur
alt
[modifier]
opt
16:click bt ajouter ( )
12:Afficher (erreur)
10:Prise en charge click ( )
9:click_bt modifier ( )
4:Click_bt consulter ( )
17:prise en charge click ( )
20:Afficher(erreur)
19:Afficher (ajout effectué)
18:Ajouter ( )
15:Saisir(details client)
14:Afficher (client inexistant )
13:Afficher (modification effectuée)
11:Mise à jour ( )
8:Saisir (modifications)
7:Afficher _details client ( )
6:Consulter ( )
5:Prise en charge click ( )
3:Saisir( critères client)
2:Selectionner (opération)
1:Dérouler liste ( )

126. Chapitre III : Conception et Analyse
Page 110
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"

127. Chapitre III : Conception et Analyse
Page 111
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

128. Chapitre III : Conception et Analyse
Page 112
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

129. Chapitre III : Conception et Analyse
Page 113
Figure 91 Diagramme séquence détaillé "Gestion référentiel crédits"
DiagrammeSequence référentiel crédit
1:Dérouler liste ( )
2:Selectionner (opération)
3:Saisir( critères crédit)
5:Prise en charge click ( ) 6:Consulter ( )
7:Afficher _details crédit ( )
8:Saisir (modifications)
11:Mise à jour ( )
13:Afficher (modification effectuée)
14:Afficher (crédit inexistant )
15:Saisir(details crédit)
18:Ajouter ( )
19:Afficher (ajout effectué)
20:Afficher(erreur)
17:prise en charge click ( )
4:Click_bt consulter ( )
9:click_bt modifier ( )
10:Prise en charge click ( )
12:Afficher (erreur)
16:click bt ajouter ( )
<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel
crédit
IU_ajouter crédit GEST_gestion référentiel
crédit
crédit
[consulter]
opt
crédit existant
crédit inexistant
alt
erreur
succès
alt
[ajouter crédit]
opt
succès
erreur
alt
[modifier]
opt
1:Dérouler liste ( )
2:Selectionner (opération)
3:Saisir( critères crédit)
5:Prise en charge click ( ) 6:Consulter ( )
7:Afficher _details crédit ( )
8:Saisir (modifications)
11:Mise à jour ( )
13:Afficher (modification effectuée)
14:Afficher (crédit inexistant )
15:Saisir(details crédit)
18:Ajouter ( )
19:Afficher (ajout effectué)
20:Afficher(erreur)
17:prise en charge click ( )
4:Click_bt consulter ( )
9:click_bt modifier ( )
10:Prise en charge click ( )
12:Afficher (erreur)
16:click bt ajouter ( )

130. Chapitre III : Conception et Analyse
Page 114
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"

131. Chapitre III : Conception et Analyse
Page 115
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 :

132. Chapitre III : Conception et Analyse
Page 116
Figure 95 Diagramme séquence détaillé "Gestion utilisateurs"
DiagrammeSequence utilisateur
14:Click_bt supprimer ( ) 16:Supprimer ( )
21:click bt ajouter ( )
18:Afficher ( erreur)
12:Afficher (erreur)
10:Prise en charge click ( )
9:click_bt modifier ( )
4:Click_bt consulter ( )
22:prise en charge click ( )
25:Afficher(erreur)
24:Afficher (ajout effectué)
23:Ajouter ( )
20:Saisir(details utilisateur)
19:Afficher (utilisateur inexistant )
17:Afficher (suppression effectuée)
15:prise en charge click ( )
13:Afficher (modification effectuée)
11:Mise à jour ( )
8:Saisir (modifications)
7:Afficher_details utilisateur ( )
6:Consulter ( )
5:Prise en charge click ( )
3:Saisir( critères utilisateur)
2:Selectionner (opération)
1:Dérouler liste ( )
<<Administrateur BCT>> IU_menu principal IU_consulter utilisateur IU_ajouter utilisateur GEST_gestion utilisateur utilisateur
[consulter]
opt
utilisateur existant
utilisateur inexistant
alt
erreur
succès
alt
[ajouter utilisateur]
opt
succès
erreur
alt
[modifier]
opt
[supprimer]
opt
succès
erreur
alt
14:Click_bt supprimer ( ) 16:Supprimer ( )
21:click bt ajouter ( )
18:Afficher ( erreur)
12:Afficher (erreur)
10:Prise en charge click ( )
9:click_bt modifier ( )
4:Click_bt consulter ( )
22:prise en charge click ( )
25:Afficher(erreur)
24:Afficher (ajout effectué)
23:Ajouter ( )
20:Saisir(details utilisateur)
19:Afficher (utilisateur inexistant )
17:Afficher (suppression effectuée)
15:prise en charge click ( )
13:Afficher (modification effectuée)
11:Mise à jour ( )
8:Saisir (modifications)
7:Afficher_details utilisateur ( )
6:Consulter ( )
5:Prise en charge click ( )
3:Saisir( critères utilisateur)
2:Selectionner (opération)
1:Dérouler liste ( )

133. Chapitre III : Conception et Analyse
Page 117
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

134. Chapitre III : Conception et Analyse
Page 118
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"

135. Chapitre III : Conception et Analyse
Page 119
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

136. Chapitre III : Conception et Analyse
Page 120
Figure 99 Diagramme de classe global
référer 1..1
1..*
examiner
appartenir
1..1
1..1
verifier
1..1
1..1
0..*
0..*
importer
extraire
correspondre
chercher
couvrir prendre
1..*
1..1
1..*
1..1
1..1 1..*
1..*
1..1
0..*
0..*
0..*
0..*
1
1..*
1
1..*
1..1
1..*
référentiel banque
-
-
-
-
-
-
-
code banque
lib
tel
fax
abréviation
adresse
categorie
: String
: String
: int
: int
: String
: String
: String
+
+
+
consulter ()
mise à jour ()
ajouter ()
garantie crédit
-
-
-
-
id_ garantie crédit
montant des garanties
date_date_mremb
date échéance
: int
: float
: Date
: Date
+
+
+
+
consulter ()
mise à jour ()
ajouter ()
supprimer ()
référentiel crédit
-
-
-
code crédit
libl_court
libl_long
: String
: String
: String
+
+
+
consulter ()
mise à jour ()
ajouter ()
portefeuille crédit
-
-
-
-
-
-
-
-
id_portefeuille crédit
forme crédit
date-deblocage
date-echeance
montant
etat
code rejet
flag rejet
: int
: String
: Date
: Date
: float
: String
: String
: char
+
+
+
+
consulter ()
mise à jour ()
ajouter ()
supprimer ()
référentiel client
-
-
identifiant
raison_soc
: String
: int
+
+
+
consulter ()
mise à jour ()
ajouter ()
...
USER
-
-
-
-
-
-
code_user
nom,prenom
login
mot de passe
mail
profil
: String
: String
: String
: String
: String
: String
+
+
+
+
consulter ()
mise à jour ()
ajouter ()
supprimer ()
...
référentiel bon trésor
-
-
-
-
-
codeisin
lib
unite
taux_nominal
categorie
: String
: String
: int
: int
: String
+
+
+
consulter ()
mise à jour ()
ajouter ()
Administrateur
-
-
id_administrateur
code_ad
: int
: String
garantie bon trésor
-
-
-
-
id_garantie bon trésor
nbr_bon
date mremb
date échéance
: int
: int
: Date
: Date
+
+
+
+
consulter ()
mise à jour ()
ajouter ()
supprimer ()
encours bon du trésor
-
-
-
-
-
id_encours bon trésor
date_encours
categorie
encours
date_échéance
: int
: Date
: String
: float
: int
+
+
+
+
consulter ()
mise à jour ()
ajouter ()
supprimer ()
...
operation de refinancement
-
-
-
-
-
-
-
-
-
code_operation
date_operation
donneur
receveur
montant
num_operation
taux
duree
date échéance
: String
: Date
: String
: String
: float
: int
: int
: float
: int
+ consulter ()
encours crédit
-
-
-
code encours
date_encours
encours
: String
: Date
: float
+
+
+
+
consulter ()
mise à jour ()
ajouter ()
supprimer ()
...
historique
archive enregistrement

137. Chapitre III : Conception et Analyse
Page 121
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.

138. Chapitre IV : Implémentation
Page 122
Chapitre IV :
Implémentation

139. Chapitre IV : Implémentation
Page 123
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

140. Chapitre IV : Implémentation
Page 124
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

141. Chapitre IV : Implémentation
Page 125
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

142. Chapitre IV : Implémentation
Page 126
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

143. Chapitre IV : Implémentation
Page 127
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 :

144. Chapitre IV : Implémentation
Page 128
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]

145. Chapitre IV : Implémentation
Page 129
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

146. Chapitre IV : Implémentation
Page 130
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 :

147. Chapitre IV : Implémentation
Page 131
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 :

148. Chapitre IV : Implémentation
Page 132
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:

149. Chapitre IV : Implémentation
Page 133
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 :

150. Chapitre IV : Implémentation
Page 134
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:

151. Chapitre IV : Implémentation
Page 135
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 :

152. Chapitre IV : Implémentation
Page 136
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:

153. Chapitre IV : Implémentation
Page 137
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:

154. Chapitre IV : Implémentation
Page 138
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 :

155. Chapitre IV : Implémentation
Page 139
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 :

156. Chapitre IV : Implémentation
Page 140
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 :

157. Chapitre IV : Implémentation
Page 141
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.

158. Conclusion Générale
Page 142
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.

159. Webographie
Page 143
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)

160. Bibliographie
Page 144
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