Académique Documents
Professionnel Documents
Culture Documents
Rapport Final Bouguerra Khadijaesseghaier Lina
Rapport Final Bouguerra Khadijaesseghaier Lina
A mes très chers amis, votre affection et votre soutien m’ont été d’un
grand secours au long de ma vie professionnelle et personnelle.
A mon aimable binôme, sans qui ce projet n’aurait pas lieu, je ne
remercierai jamais assez dieu de t’avoir mise sur mon chemin.
Aux membres de mon honorable grande famille, mes oncles, mes tantes,
mes cousins et mes cousines que je chéris tant et qui m’ont guidé vers le bon
chemin.
A la famille « Esseghaier », qui m’ont accueillie à bras ouverts dans
leur famille,
Khadija Bouguerra
Dédicaces
Ma reconnaissance se tourne en premier lieu vers Dieu le tout puissant.
Je dédie par la suite ce modeste travail
A mon Père Aucune dédicace ne saurait exprimer l’amour, l’estime, le
respect que j’ai toujours eu pour toi. Rien au monde ne vaut tes efforts pour
mon éducation et mon bien être
A ma très chère mère la prunelle de mes yeux, la source de tendresse tu
n’as pas cessé de m’encourager et de prier pour moi. Tes prières m’ont été
d’un grand secours
A mon frère Rien ne suffit pour exprimer l’attachement, l’amour et
l’affection que je porte pour toi. Mon fidèle compagnon dans les moments les
plus délicats de cette vie mystérieuse.
A ma merveilleuse et exceptionnelle grand-mère maternelle qui a tant
sacrifié pour nous. A tous les membres de ma famille, petits et grands
A ma binôme Bien plus qu’une amie une sœur, qui m’a soutenu et
supporté dans les moments les plus difficiles Ce fut un grand plaisir de
travailler avec toi. Je souhaite une longue vie à notre amitié
Lina Esseghaier
Remerciement
Nos sincères remerciements s’adressent en premier lieu à notre
encadreur Monsieur Ahmed Badreddine pour l’aide efficace qu’elle nous
a apporté dans l’élaboration de ce modeste travail. Nous avons pu
apprécier à sa juste valeur combien sa précieuse assistance a été
déterminante pour la réalisation de ce projet. Qu’elle trouve à travers ce
remerciement le signe de notre reconnaissance et notre profonde gratitude.
3. Etude de l'existant................................................................................................. 7
7. Conclusion ........................................................................................................ 18
4. Conclusion .......................................................................................................... 80
2.3.1. Prototypes des interfaces du cas Gestion Encours Bon du trésor ............. 89
2.7.1. Prototypes des interfaces du cas « Gestion Référentiel Bons du Trésor 102
2.8.1. Prototypes des interfaces du cas « Gestion Référentiel Clients » .......... 106
2.9.1. Prototypes des interfaces du cas « Gestion Référentiel Crédits » .......... 110
2.10.3. Diagramme de séquence détaillé du cas « Gestion des utilisateurs »... 115
................................................................................................................................ 140
Introduction Générale
Depuis que le monde est monde, on est sans cesse témoins de nouvelles technologies
plus révolutionnaires les unes que les autres. Et le domaine de l’informatique n’est pas
épargné de cette évolution constante. En effet, c’est le domaine qui connait le plus de
croissance. Chaque jour, de nouvelles technologies percent le marché. On cite entre autres les
nouvelles méthodologies de conception et des langages de développement apparaissant pour
résoudre les problèmes existants et dépasser les limites des versions antérieures.
Ces développements se combinent avec les simplifications administratives générales et
les services qui s’exercent dans un établissement bancaire dans notre cas.
Le présent rapport est un projet de fin d’étude réalisé en vue de l’obtention d’une
licence en Informatique de gestion. Ce rapport a été réalisé à la suite d’un stage de trois mois
au sein de la Banque Centrale de Tunisie.
Le sujet que nous aurons proposé concerne « la gestion et le suivi des contreparties
de refinancement ». Il nous a été demandé d’effectuer la conception et la réalisation d’une
application permettant la prise en charge et le suivi d’un portefeuille de créances éligibles à
une opération de refinancement et un encours de bons du trésor déclarés par la Société
Tunisienne Interprofessionnelle de Compensation des Valeurs Mobilières (STICODEVAM),
ainsi les garantis présentés par les banques en contrepartie d’une opération de refinancement
sur le marché monétaire et aussi les référentiels de ses garantis présentés.
Pour ce faire, nous adapterons « UML » comme langage de modélisation pour ce
projet, et concernant le développement de l’application, nous utiliserons les outils de
développement « ORACLE ».
Le présent rapport comporte quatre chapitres :
Dans le premier chapitre intitulé « Contexte général », nous allons présenter le cadre
de notre stage à savoir La Banque Centrale de Tunisie. Une description du système actuel
accompagnée de la problématique nous mènera à la proposition de notre solution.
Ensuite, nous identifierons les besoins fonctionnels et non fonctionnels de notre projet,
l’approche utilisée pour la conception, et enfin la méthodologie de l’architecture de travail
adoptée.
Page 1
Introduction
Dans le second chapitre intitulé « Spécification des exigences », nous allons identifier
les acteurs du système, le diagramme de cas d’utilisation global puis raffiné et nous
enchaînerons par la présentation des scénarios et le diagramme de séquence système de
chaque cas.
Le troisième chapitre « Conception et Analyse » aura pour but de faire l’analyse
détaillée et complète des cas d’utilisation identifiés dans le chapitre précédent. Nous
procèderons comme suit : on présente une maquette pour chaque interface de notre
application suivi d’un diagramme de classe participante et enfin un diagramme de séquence
détaillé. Vers la fin de ce chapitre, nous devrons établir le diagramme de classe global qui va
nous permettre d’identifier les différentes entités du système.
Dans le dernier chapitre, nous porterons sur l’implémentation de la solution proposée
en donnant un aperçu sur l’environnement technique de développement, le cycle de vie
adopté, la création de la base de données, ainsi que la présentation des interfaces réalisées.
Page 2
Chapitre I : Contexte Général
Chapitre I :
Contexte
Général
Page 3
Chapitre I : Contexte Général
1. Introduction
Dans ce chapitre, nous allons exposer en premier lieu le cadre de notre stage.
Nous commençons par formuler une présentation de notre organisme d’accueil ainsi que la
direction qui nous a reçues. Ensuite, nous enchaînons avec l’étude de l’existant qui nous
mènera à dégager notre problématique.
Et enfin, nous formulerons les besoins fonctionnels et non fonctionnels qui vont nous
permettre de capturer les cas d’utilisation nécessaires à notre projet.
1. Présentation de l'organisme d'accueil
1.1.Historique de la BCT
La Banque Centrale de Tunisie a vu le jour deux ans après l’Independence du pays.
Elle a été créée par la loi n°58-90 du 19 Septembre 1958.
C’est un établissement public national doté de la personnalité civile et de l’autonomie
financière. La direction des affaires de la Banque Centrale est exercée par un gouverneur
nommé par décret. Ce gouverneur est assisté par un Vice-gouverneur placé sous son autorité
immédiate et chargé de veiller sur tous les services de la Banque centrale. [1]
La BCT dispose de onze comptoirs, répartis sur tout le territoire national, qui la
représentent au niveau régional.
Ces comptoirs rapprochent les services de la BCT des opérateurs économiques et
favorisent le développement de la bancarisation des régions. Ils couvrent également les
besoins des agences bancaires, des recettes PTT et du trésor public en retraits et en
versements de billets de banque et pièces de monnaie et collectent à travers le pays
l’information économique et financière à l’effet de procéder à une analyse de la conjoncture
au niveau de la région.
1.2.Rôle de la BCT
Le rôle principal de la BCT est de coordonner entre plusieurs organismes, aussi bien à
l’intérieur du pays qu’à l’extérieur. La BCT présente le centre d’affluence d’une classe
importante d’informations et guide la politique de l’état en matière de change extérieur. Elle
participe à l’orientation de l’économie de la production en fonction des objectifs de la
politique économique et sociale du pays.
Ce rôle important la met en relation avec plusieurs organismes tels que la douane, le
ministère des finances, les ministères de l’économie, les administrations, les universités etc.
Page 4
Chapitre I : Contexte Général
Page 5
Chapitre I : Contexte Général
2.4.Mission de la D.G.S.I
La Direction Générale des Système d’Information est chargée de concevoir le système
d’information de la banque et d’établir le plan d’informations en fonction des besoins des
utilisateurs et des options arrêtées par le comité informatique. Elle assure, par ailleurs,
l’évaluation harmonieuse des applications, la gestion des équipements informatiques et la
sécurité informatique.
Cependant, la direction présente un certain nombre de problèmes. En effet, plusieurs
opérations sont accomplies manuellement, ce qui rend le travail assez long et pénible.
D'autant plus que le système existant est assez complexe et présente beaucoup d'insuffisances.
3. Etude de l'existant
3.1.Description de l'existant
La banque centrale de Tunisie (BCT) se réserve de prendre à son compte certaines
opérations de refinancement lorsqu’elle jugera nécessaire pour assurer l’équilibre du marché.
Une opération de refinancement représente une intervention de la banque centrale de
Tunisie au profit des banques pour fournir liquidités et faciliter leurs trésoreries.
L’intervention de la BCT peut prendre les formes suivantes :
Injection : Dans le cadre de l’équilibre monétaire, la BCT intervient pour fournir des
liquidités, à la demande des banques, sur le marché monétaire. Cette intervention permet au
taux du marché de se stabiliser et de ne plus croitre.
La BCT informe les banques qu’elle est prête à fournir des liquidités avec le taux du
marché.
On remarque avec cette opération que le taux est fixé par la BCT.
Appel d’offre positif : la BCT détermine périodiquement, en fonction de l’évolution
de la liquidité des banques, le volume de la monnaie centrale qu’elle est disposée à fournir.
A cet effet la BCT informe les banques de dépôts et d’investissement de son intention
d’alimenter en liquidité le marché sous forme d’appel d’offre.
Pension à 7 jours : la BCT interviendra sur le marché monétaire pour fournir des
liquidités sous forme de prise en pension pour une durée variant entre un et sept jours.
La banque centrale de Tunisie admet, en contrepartie des opérations de refinancement
des banques sur le marché monétaire, les effets publics négociables(les bons du trésor) et
les crédits offerts par les banques pour les entreprises et les particuliers.
3.1.1. Les crédits
Il s’agit des crédits offerts par les banques pour les entreprises et les particuliers.
Page 7
Chapitre I : Contexte Général
Les banques d’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
4. Etude du sujet
4.1.Problématique
Comme il a été déjà été mentionné, la direction générale des systèmes d’information
rencontre des problèmes notamment au niveau des échanges de données entre le service du
marché monétaire et le service de contrôle de refinancement.
Les principales insuffisances et limites du système existant sont :
Page 10
Chapitre I : Contexte Général
Manque de sécurité des données : le transfert manuel des dossiers entre le service du
marché monétaire et le service de contrôle de refinancement peut provoquer la perte des
données.
Vérification des crédits à mettre en garantie par un contrôle visuel sur les fichiers
EXCEL envoyés par les banques.
Vérification des bons du trésor à mettre en garantie par un visuel sur les fichiers
EXCEL envoyés par les banques.
L’utilisateur ne bénéficie pas de tableaux de bord fiables et conviviaux dans le cadre du
suivi des portefeuilles des crédits des banques.
Page 11
Chapitre I : Contexte Général
Page 12
Chapitre I : Contexte Général
Page 14
Chapitre I : Contexte Général
Page 15
Chapitre I : Contexte Général
Diagramme Scénario
Diagramme Diagramme Diagramme Diagramme
Besoins de cas détaillé de
séquence de classe de séquence de classe
fonctionnels d'utilisation chaque cas
système participante détaillé global
initial d'utilisation
Page 16
Chapitre I : Contexte Général
Page 17
Chapitre I : Contexte Général
7. Conclusion
Nous avons présenté au niveau de ce chapitre notre organisme d'accueil, son rôle, son
pouvoir ainsi que la direction dans laquelle on a travaillé.
Nous avons également dégagé notre problématique et étudié scrupuleusement les
solutions possibles pour remédier à ces insuffisances.
Ce qui nous a amené à la proposition de notre solution et identifier par la suite les
besoins fonctionnels et non fonctionnels.
Page 18
Chapitre II : Spécification des Exigences
Chapitre II :
Spécification
Des
Exigences
Page 19
Chapitre II : Spécification des Exigences
1. Introduction
Le but principal de ce deuxième chapitre consiste à analyser les différents besoins
fonctionnels et non fonctionnels identifiés dans le chapitre précédent.
Nous débutons par présenter les différents acteurs du système. Ensuite, on entre dans
le vif du sujet en définissant les différents cas d’utilisation relatifs aux besoins. Et enfin, on
termine par établir un scenario correspondant à chaque cas d’utilisation afin d’élaborer les
diagrammes de séquences système.
C’est en se basant sur l'étude de l’existant qu’on pourra déceler le fond du problème et
trouver la solution adéquate pour y remédier.
Il convient donc d’y prêter une grande attention pour la rendre la plus claire et la
moins ambiguë possible, puisque tout ce qui suit dépendra de sa qualité.
2. Spécification générale des exigences
La spécification générale des exigences se fait à travers le diagramme de cas
d’utilisation inspiré des besoins identifiés dans le premier chapitre.
Pour établir ce diagramme, on doit tout d’abord identifier les acteurs du système et par
la suite les cas d’utilisation.
2.1.Identification des acteurs
Un acteur est une entité externe qui interagit avec le système (opérateur, centre distant,
autre système...). En réponse à l'action d'un acteur, le système fournit un service qui
correspond à son besoin. Les acteurs peuvent être classés (hiérarchie). [7]
Dans notre application on distingue deux intervenants qui interagissent avec
l’interface :
L’utilisateur BCT : c’est celui qui se charge de la gestion des contreparties de
refinancement.
Administrateur : Il peut effectuer les mêmes opérations que l’utilisateur BCT à une
différence près. En effet, il assure la gestion des utilisateurs aussi.
2.2.Identification des cas d’utilisation
Après avoir identifié les différents besoins de notre système, on procède à l’expression
des cas d’utilisation. Nous présentons dans la figure numéro 5, le diagramme de cas
d’utilisation initial permettant d’associer chaque cas d’utilisation à l’acteur qui lui correspond.
Page 20
Chapitre II : Spécification des Exigences
<<include>>
Gèrer portefeuille crédit
<< include>>
Gèrer encours bon du trésor
<<include>>
Gèrer référentiel clients s'authentifier
<<include>>
Gèrer référentiel crédits
<<include>>
Gèrer garanties bons du trésor
<<include>>
Gèrer Utilisateurs
<<include>>
<<Administrateur>>
Page 21
Chapitre II : Spécification des Exigences
Page 22
Chapitre II : Spécification des Exigences
S'authentifier
<<Utilisateur BCT>>
Acteur_2
Dans le Tableau 3 qui suit, nous allons décrire le scénario détaillé de l’authentification :
Page 23
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 7 :
Authentification
<<system>>
Refinancement
<<Utilisateur BCT>>
1:Saisir(login,mot_de_passe)
alt Erreur
Succès
3:Afficher le menu principal()
<<Utilisateur BCT>>
<<extend>> <<extend>>
<<System>>
Refinancement
<<Utilisateur BCT>>
alt
valides
2:Afficher(Ajout accepté)
invalides
3:Afficher (erreur)
Page 25
Chapitre II : Spécification des Exigences
Dans le tableau 5 qui suit, nous allons décrire le scénario détaillé de la consultation d’un
crédit dans le Portefeuille:
Cas Consulter un crédit du portefeuille
d’utilisation
Acteur Utilisateur BCT
Pré condition L’utilisateur BCT identifié et autorisé
Post condition Consultation effectuée
Scénario -L’utilisateur BCT saisit les critères de recherche d’un crédit
principal -Le système cherche dans la base de données
-Le système affiche tous les détails du crédit recherché
Exception -L’utilisateur BCT introduit une valeur erronée, laisse un champ vide ou un critère
introuvable.
-Le système cherche dans la base de données
-Le système affiche un message d’erreur.
Extension -Modifier un crédit
-Supprimer un crédit
Page 26
Chapitre II : Spécification des Exigences
consulter portefeuille crédit
<<System>>
Refinancement
<<Utilisateur BCT>>
2:Afficher_details crédit ( )
crédit inexistant
3:Afficher (crédit inexistant)
critères invalides
4:Afficher (erreur)
Page 27
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
<<Utilisateur BCT>>
1:Saisir (modifications)
alt succès
erreur
3:Afficher (erreur )
Page 28
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
<<Utilisateur BCT>>
Page 29
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
<<Utilisateur BCT>>
alt succès
2:Afficher(suppression effectuée)
erreur
3:Afficher (erreur)
Page 30
Chapitre II : Spécification des Exigences
<<Utilisateur BCT>>
Consulter bon du trésor Ajouter bon du trésor Verifier échéance bon du trésor
<<extend>> <<extend>>
Page 31
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
<<Utilisateur BCT>>
alt
valides
2:Afficher (ajout accepté)
invalides
3:Afficher (erreur)
Page 32
Chapitre II : Spécification des Exigences
Page 33
Chapitre II : Spécification des Exigences
consulter encours bon trésor
<<System>>
Refinancement
<<Utilisateur BCT>>
critères invalides
4:Afficher (erreur)
Page 34
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
<<Utilisateur BCT>>
alt succès
erreur
3:Afficher (erreur)
Page 35
Chapitre II : Spécification des Exigences
Dans le tableau 12 qui suit, nous allons décrire le scénario détaillé de la modification d’un bon
du trésor
<<System>>
Refinancement
<<Utilisateur BCT>>
1:Saisir (modifications)
alt succès
erreur
3:Afficher (erreur)
Page 36
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 19 :
Page 37
Chapitre II : Spécification des Exigences
verification echeance bon trésor
<<System>>
Refinancement
<<Utilisateur BCT>>
Page 38
Chapitre II : Spécification des Exigences
<<Utilisateur BCT>>
<<extend>> <<extend>>
Page 39
Chapitre II : Spécification des Exigences
Page 40
Chapitre II : Spécification des Exigences
Ajouter garantie crédit
<<system>>
Refinancement
<<Utilisateur BCT>>
1:Saisir(date opération)
alt Valide
2:Afficher(opération de refinancement)
3:Sélectionner(crédit)
4:Afficher(Ajout effectué)
Invalide
5:Afficher(erreur)
Page 41
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
<<Utilisateur BCT>>
1:Saisir (modifications)
alt succès
2:Afficher(modification effectuée)
erreur
3:Afficher (erreur )
Page 42
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 23:
consulter garantie crédit
<<System>>
Refinancement
<<Utilisateur BCT>>
critères invalides
4:Afficher (erreur)
Page 43
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
<<Utilisateur BCT>>
alt succès
erreur
3:Afficher (erreur)
Page 44
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 25 :
Page 45
Chapitre II : Spécification des Exigences
Consulter operation refinancement
<<System>>
Refinancement
<<Utilisateur BCT>>
operation inexistante
3:Afficher(operation de refinancement
inexistante)
critères invalides
4:Afficher (erreur)
Page 46
Chapitre II : Spécification des Exigences
<<Utilisateur BCT>>
Consulter operation de
Consulter garantie bons du trésor Ajouter garantie bons du trésor refinancement
<<extend>> <<extend>>
Page 47
Chapitre II : Spécification des Exigences
Extension -
Page 48
Chapitre II : Spécification des Exigences
Ajouter garantie bon du trésor
<<system>>
Refinancement
<<Utilisateur BCT>>
1:Saisir(date opération)
alt Valide
2:Afficher(opération de refinancement)
3:Sélectionner(bon du trésor)
4:Afficher(Ajout effectué)
Invalide
5:Afficher(erreur)
Page 49
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
<<Utilisateur BCT>>
1:Saisir (modifications)
alt succès
erreur
3:Afficher (erreur)
Page 50
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 29:
Page 51
Chapitre II : Spécification des Exigences
sequence consulter garantie bon trésor
<<System>>
Refinancement
<<Utilisateur BCT>>
critères invalides
4:Afficher (erreur )
Page 52
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
<<Utilisateur BCT>>
alt succès
2:Afficher(suppression effectuée)
erreur
3:Afficher (erreur)
Page 53
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 31:
Page 54
Chapitre II : Spécification des Exigences
Consulter operation refinancement
<<System>>
Refinancement
<<Utilisateur BCT>>
operation inexistante
3:Afficher(operation de refinancement
inexistante)
critères invalides
4:Afficher (erreur)
Page 55
Chapitre II : Spécification des Exigences
<<extend>>
Modifier crédit
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans
la figure 33:
Page 56
Chapitre II : Spécification des Exigences
Sequence ajouter référentiel crédit
<<System>>
Refinancement
<<Utilisateur BCT>>
alt
valides
2:Afficher (ajout accepté)
invalides
Page 57
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 34:
Sequence consulter référentiel crédit
<<System>>
Refinancement
<<Utilisateur BCT>>
critères invalides
4:Afficher (erreur )
Page 58
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
<<Utilisateur BCT>>
1:Saisir (modifications)
alt succès
erreur
3:Afficher (erreur)
Page 59
Chapitre II : Spécification des Exigences
<<Utilisateur BCT>>
<<extend>>
Page 60
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 37:
Sequence ajouter référentiel bon trésor
<<System>>
Refinancement
<<Utilisateur BCT>>
alt
valides
2:Afficher (ajout accepté )
invalides
3:Afficher(erreur)
Page 61
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 38:
Sequence consulter référentiel bon trésor
<<System>>
Refinancement
<<Utilisateur BCT>>
critères invalides
4:Afficher (erreur )
Page 62
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 39:
Sequence modifier référentiel bon trésor
<<System>>
Refinancement
<<Utilisateur BCT>>
1:Saisir (modifications)
alt succès
erreur
3:Afficher (erreur )
Page 63
Chapitre II : Spécification des Exigences
<<extend>>
Modifier client
Page 64
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 41:
Sequence ajouter référentiel client
<<System>>
Refinancement
<<Utilisateur BCT>>
alt
valides
2:Afficher (ajout accepté )
invalides
3:Afficher(erreur )
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 42:
Page 65
Chapitre II : Spécification des Exigences
Sequence consulter référentiel client
<<System>>
Refinancement
<<Utilisateur BCT>>
critères invalides
4:Afficher (erreur )
Page 66
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 43:
Sequence modifier référentiel client
<<System>>
Refinancement
<<Utilisateur BCT>>
1:Saisir (modifications)
alt succès
erreur
3:Afficher (erreur )
Page 67
Chapitre II : Spécification des Exigences
<<extend>>
Modifier banque
Page 68
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 45:
Sequence ajouter référentiel banque
<<System>>
Refinancement
<<Utilisateur BCT>>
alt
valides 2:Afficher (ajout accepté)
invalides
3:Afficher (erreur)
Page 69
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 46:
Sequence consulter référentiel banque
<<System>>
Refinancement
<<Utilisateur BCT>>
critères invalides
4:Afficher (erreur )
Page 70
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 47:
Sequence modifier référentiel banque
<<System>>
Refinancement
<<Utilisateur BCT>>
1:Saisir (modifications)
alt succès
erreur
3:Afficher (erreur)
Page 71
Chapitre II : Spécification des Exigences
Cosulter Refinancement
<<utilisateur BCT>>
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 49:
Page 72
Chapitre II : Spécification des Exigences
Consulter operation refinancement
<<System>>
Refinancement
<<Utilisateur BCT>>
operation inexistante
3:Afficher(operation de refinancement
inexistante)
critères invalides
4:Afficher (erreur)
Page 73
Chapitre II : Spécification des Exigences
<<Admi ni strateur>>
<<extend>>
<<extend>>
Page 74
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 51:
Sequence ajouter utilisateur
<<System>>
Refinancement
<<Administrateur BCT>>
alt
valides
2:Afficher( ajout accepté)
invalides
3:Afficher (erreur )
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 52:
Page 75
Chapitre II : Spécification des Exigences
Sequence consulter utilisateur
<<System>>
Refinancement
<<Administrateur BCT>>
utilisateur inexistant
3: Afficher (utilisateur inexistant)
critères invalides
4:Afficher (erreur )
Page 76
Chapitre II : Spécification des Exigences
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 53:
Sequence modifier utilisateur
<<System>>
Refinancement
<<Administrateur BCT>>
1:Saisir (modifications)
alt succès
erreur
3:Afficher(erreur )
Une représentation graphique des étapes décrites dans le tableau précédent est illustrée dans la
figure 54:
Page 77
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
<<Administrateur BCT>>
alt succès
erreur
3:Afficher (erreur)
Page 78
Chapitre II : Spécification des Exigences
<<System>>
Refinancement
+ saisir ()
+ afficher ()
+ click_bt supprimer bon trésor ()
+ click_bt_supprimer_gar_bon_tresor ()
+ click_bt supprimer crédit ()
+ click_bt supprimer utilisateur ()
+ afficher_details oper refinancement ()
+ afficher_details crédit ()
+ afficher_details bon trésor ()
+ afficher details référentiel banque ()
+ afficher_details ref bon trésor ()
+ afficher_details référentiel client ()
+ afficher_details référentiel crédit ()
+ afficher_details utilisateur ()
+ selectionner ()
Pour découper l’ensemble des opérations en groupes cohérents, il serait également possible de
commencer à définir les cinq interfaces les plus importantes, comme représenté sur la figure
dans la figure 56 :
Page 79
Chapitre II : Spécification des Exigences
4. Conclusion
A la fin de ce chapitre, nous avons pu identifier les principales fonctionnalités de notre
projet. Une liste des opérations que doit effectuer le système a été établie.
Dans le chapitre suivant, on va passer à l’analyse et à la conception des différents cas
d’utilisation.
Page 80
Chapitre III : Conception et Analyse
Chapitre III
Conception et Analyse
Page 81
Chapitre III : Conception et Analyse
1. Introduction
A partir des différentes méthodes identifiées dans le chapitre précédent, nous passons
à l’analyse des cas d’utilisation cas par cas.
Nous procédons comme suit :
Nous présentons tout d’abord une maquette pour chaque interface de notre application.
Ces maquettes vont nous permettre de définir les diagrammes de classes participantes qui
détermineront les classes de notre système.
Enfin, pour arriver à établir le diagramme de classe global, nous devons illustrer les
diagrammes séquence détaillés avant.
2. Analyse des cas d’utilisation
Nous présentons les types de diagrammes que nous allons exploiter afin d’analyser les
cas d’utilisation identifiés dans le chapitre dernier :
Nous enchaînons avec l’analyse des cas d’utilisation présentés dans chapitre précédent.
Page 82
Chapitre III : Conception et Analyse
Page 83
Chapitre III : Conception et Analyse
6:Afficher (erreur)
Page 84
Chapitre III : Conception et Analyse
d’afficher dans le deuxième bloc le crédit recherché. Outre les critères cités auparavant, six
autres champs sont représentés dans l’interface. Il s’agit de la date de déclaration, du montant,
de l’encours, de l’état, de la date garantie et du rejet. On a deux possibilités d’opérations :
Modifier ou Supprimer.
Et enfin le dernier prototype symbolise la sélection des tombées. L’utilisateur doit
introduire une date, clique sur le bouton supprimer et le système supprime tous les crédits
ayant la date d’échéance inférieure à la date saisie.
Page 85
Chapitre III : Conception et Analyse
Page 86
Chapitre III : Conception et Analyse
Le flux des messages entre les différents objets du système est représenté dans le
diagramme illustré dans la figure 64:
Page 87
Chapitre III : Conception et Analyse
Diag sequence portefeuille crédit
<<Utilisateur BCT>> IU_menu principal IU_consulter crédit IU_ajouter crédit IU_selection des tombées GEST_gestion portefeuille portefeuille crédit encours crédit référentiel client référentiel banque référentiel crédit
crédit
1:Dérouler liste ( )
2:Selectionner (opération)
opt [consulter]
opt [modifier]
8:Saisir (modifications)
alt erreur
13:Afficher (erreur)
succès
erreur
20:Afficher ( erreur)
crédit inexistant
alt
succès
30:Afficher (ajout effectué)
erreur
31:Afficher(erreur)
Page 88
Chapitre III : Conception et Analyse
Page 89
Chapitre III : Conception et Analyse
Page 90
Chapitre III : Conception et Analyse
Page 91
Chapitre III : Conception et Analyse
sequence encours bon du trésor
<<Utilisateur BCT>> IU_menu principal IU_consulter bon trésor IU_ajouter bon trésor IU_verifier échéance GEST_gestion encours encours bon du trésor référentiel banque référentiel bon du trésor
bon du trésor
1:Dérouler liste ( )
2:Selectionner (opération)
opt [consulter]
opt [modifier]
8:Saisir (modifications)
9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )
alt erreur
12:Afficher (erreur)
succès
opt [supprimer]
14:Click_bt supprimer ( ) 15:prise en charge click ( ) 16:Supprimer ( )
alt succès
erreur
27:Afficher(erreur)
Page 92
Chapitre III : Conception et Analyse
Page 93
Chapitre III : Conception et Analyse
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 »
Page 94
Chapitre III : Conception et Analyse
<<Utilisateur BCT>> IU_menu principal IU_consulter garantie IU_consulter operation GEST_gestion garantie encours crédit garantie crédit operation refinancement portefeuille crédit
crédit refinancement crédit
1:Dérouler liste ( )
2:Selectionner (opération)
opt [consulter]
opt [Modifier]
8:Saisir (modifications)
9:Click_bt modifier ( )
10:Prise en charge click ( )
11:Mise à jour ( )
alt erreur
12:Afficher (erreur)
succès
opt [Supprimer]
14:Click_bt supprimer 15:Prise en charge click( ) 16:Supprimer ( )
alt succès
erreur
18:Afficher (erreur)
erreur
27:Afficher (erreur)
alt succès
32:Afficher_details operation de
refinancement( )
erreur
33:Afficher (erreur)
Page 95
Chapitre III : Conception et Analyse
Page 96
Chapitre III : Conception et Analyse
Page 97
Chapitre III : Conception et Analyse
<<Utilisateur BCT>> IU_menu principal IU_consulter garantie bon IU_consulter operation GEST_gestion garantie encours bon du trésor garantie bon du trésor operation refinancement
trésor refinancement bon du trésor
1:Dérouler liste ( )
2:Selectionner (opération)
opt [consulter]
opt [Modifier]
8:Saisir (modifications)
9:Click_bt modifier ( )
10:Prise en charge click ( )
11:Mise à jour ( )
alt erreur
12:Afficher (erreur)
succès
opt [Supprimer]
14:Click_bt supprimer 15:Prise en charge click( )
alt succès
16:Supprimer ( )
17:Afficher (suppression effectuée)
erreur
18:Afficher (erreur)
alt succès
25:Afficher (succès)
erreur
26:Afficher (erreur)
alt succès
31:Afficher(details operation de
refinancement)
erreur
32:Afficher(erreur)
Page 98
Chapitre III : Conception et Analyse
Page 99
Chapitre III : Conception et Analyse
Page 100
Chapitre III : Conception et Analyse
DiagrammeSequence référentiel banque
<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel IU_ajouter banque GEST_gestion référentiel banque
banque banque
1:Dérouler liste ( )
2:Selectionner (opération)
opt [consulter]
opt [modifier]
8:Saisir (modifications)
9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )
succès
banque inexistante
15:Saisir(critères banque)
16:click bt ajouter ( ) 17:prise en charge click ( ) 18:Ajouter ( )
alt succès
erreur
20:Afficher(erreur)
Page 101
Chapitre III : Conception et Analyse
Page 102
Chapitre III : Conception et Analyse
Page 103
Chapitre III : Conception et Analyse
Page 104
Chapitre III : Conception et Analyse
DiagrammeSequence référentiel bon trésor
<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel IU_ajouter bon trésor GEST_gestion référentiel bon du trésor
bon trésor bon du trésor
1:Dérouler liste ( )
2:Selectionner (opération)
opt [consulter]
opt [modifier]
8:Saisir (modifications)
9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )
succès
erreur
20:Afficher(erreur)
Page 105
Chapitre III : Conception et Analyse
Page 106
Chapitre III : Conception et Analyse
Page 107
Chapitre III : Conception et Analyse
Page 108
Chapitre III : Conception et Analyse
DiagrammeSequence référentiel client
<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel IU_ajouter client GEST_gestion référentiel client
client client
1:Dérouler liste ( )
2:Selectionner (opération)
opt [consulter]
4:Click_bt consulter ( )
5:Prise en charge click ( ) 6:Consulter ( )
opt [modifier]
8:Saisir (modifications)
9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )
alt erreur
12:Afficher (erreur)
succès
client inexistant
15:Saisir(details client)
erreur
20:Afficher(erreur)
Page 109
Chapitre III : Conception et Analyse
Page 110
Chapitre III : Conception et Analyse
Page 111
Chapitre III : Conception et Analyse
Page 112
Chapitre III : Conception et Analyse
DiagrammeSequence référentiel crédit
<<Utilisateur BCT>> IU_menu principal IU_consulter référentiel IU_ajouter crédit GEST_gestion référentiel crédit
crédit crédit
1:Dérouler liste ( )
2:Selectionner (opération)
opt [consulter]
4:Click_bt consulter ( )
5:Prise en charge click ( ) 6:Consulter ( )
opt [modifier]
8:Saisir (modifications)
9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )
succès
crédit inexistant
15:Saisir(details crédit)
erreur
20:Afficher(erreur)
Page 113
Chapitre III : Conception et Analyse
Page 114
Chapitre III : Conception et Analyse
Page 115
Chapitre III : Conception et Analyse
DiagrammeSequence utilisateur
<<Administrateur BCT>> IU_menu principal IU_consulter utilisateur IU_ajouter utilisateur GEST_gestion utilisateur utilisateur
1:Dérouler liste ( )
2:Selectionner (opération)
opt [consulter]
opt [modifier]
8:Saisir (modifications)
9:click_bt modifier ( )
10:Prise en charge click ( ) 11:Mise à jour ( )
alt erreur
12:Afficher (erreur)
succès
alt succès
utilisateur inexistant
20:Saisir(details utilisateur)
21:click bt ajouter ( ) 22:prise en charge click ( ) 23:Ajouter ( )
alt succès
erreur
25:Afficher(erreur)
Page 116
Chapitre III : Conception et Analyse
Page 117
Chapitre III : Conception et Analyse
Page 118
Chapitre III : Conception et Analyse
Page 119
Chapitre III : Conception et Analyse
référentiel bon trésor
- codeisin : String
référentiel crédit
- lib : String
- code crédit : String - unite : int
- libl_court : String - taux_nominal : int
- libl_long : String - categorie : String
+ consulter () + consulter ()
+ mise à jour () + mise à jour ()
+ ajouter () + ajouter ()
1..1
1..1
encours crédit
verifier
- code encours : String
examiner - date_encours : Date
1..1
- encours : float
+ consulter () encours bon du trésor
1..1 + mise à jour ()
- id_encours bon trésor : int
+ ajouter ()
- date_encours : Date
portefeuille crédit + supprimer ()
- categorie : String
...
- id_portefeuille crédit : int 1..* - encours : float
- forme crédit : String - date_échéance : int
- date-deblocage : Date + consulter ()
- date-echeance : Date correspondre référentiel banque + mise à jour ()
- montant : float + ajouter ()
- code banque : String
- etat : String + supprimer ()
1..* - lib : String
- code rejet : String 1..1 ...
- tel : int
- flag rejet : char 1..*
- fax : int 1..*
+ consulter () - abréviation : String
+ mise à jour () - adresse : String chercher
+ ajouter () référer 1..1 - categorie : String extraire
1..* 1..1
+ supprimer ()
+ consulter ()
+ mise à jour () 1
+ ajouter ()
garantie bon trésor
1..* - id_garantie bon trésor : int
importer - nbr_bon : int
- date mremb : Date
- date échéance : Date
1 + consulter ()
+ mise à jour ()
garantie crédit operation de refinancement
+ ajouter ()
- id_ garantie crédit : int - code_operation : String + supprimer ()
- montant des garanties : float 1..1 - date_operation : Date prendre
appartenir 1..* couvrir 1..1 1..*
- date_date_mremb : Date - donneur : String
- date échéance : Date - receveur : String
+ consulter () - montant : float
+ mise à jour () - num_operation : int
+ ajouter () - taux : int
+ supprimer () - duree : float 0..*
- date échéance : int
+ consulter ()
0..*
0..*
historique
1..1
référentiel client
- identifiant : String
0..*
- raison_soc : int
+ consulter () USER
+ mise à jour () - code_user : String
+ ajouter () - nom,prenom : String
... - login : String
- mot de passe : String
- mail : String
0..* - profil : String 0..*
+ consulter ()
+ mise à jour ()
+ ajouter ()
archive + supprimer () enregistrement
...
Administrateur
- id_administrateur : int
- code_ad : String
Page 120
Chapitre III : Conception et Analyse
4. Conclusion
L’analyse des cas d’utilisation ainsi que la conception rencontrés au cours de ce
chapitre nous permettent désormais d’identifier les classes nécessaires pour la réalisation de
notre projet. Nous allons alors détailler dans le chapitre 4, les différentes phases de réalisation
de notre projet.
Page 121
Chapitre IV : Implémentation
Chapitre IV :
Implémentation
Page 122
Chapitre IV : Implémentation
1. Introduction
Ce chapitre a pour but de décrire les solutions techniques retenues pour
l’implémentation de notre projet.
Nous commençons par générer notre base de données relationnelle en se basant sur le
diagramme de classe global établie dans le chapitre précédent. Par la suite, on passe à la
description de l’architecture physique de notre application en établissant un diagramme de
déploiement. Et enfin, nous allons présenter des captures d’écrans des interfaces de notre
application pour avoir une idée générale sur son fonctionnement.
2. Génération des tables
Dans ce qui suit, nous allons présenter les tables de notre base de données :
Page 123
Chapitre IV : Implémentation
EncoursCrédit)
Table EncoursCrédits
Page 124
Chapitre IV : Implémentation
Page 125
Chapitre IV : Implémentation
du trésor)
Nbr_bon NUMBER Nombre de bons pris en garantie
Date_mremb DATE -Date mise en garantie
Table utilisateurs
Page 126
Chapitre IV : Implémentation
Table OpérationRefinancement
3. Diagramme de déploiement
Les diagrammes de déploiement sont utilisés pour représenter l’architecture physique
d’un système. Ils montrent la distribution des composants logiciels sur la base d’unités
d’exécution (les nœuds).
Les nœuds et les artéfacts représentent le concept principal du diagramme de déploiement.
Les diagrammes de déploiement peuvent être créés sur les packages, les classes, les
interfaces, les composants, les artéfacts et les nœuds. [8]
La figure 100 jointe ci-dessous représente le diagramme de déploiement :
Page 127
Chapitre IV : Implémentation
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 :
Page 128
Chapitre IV : Implémentation
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]
Page 130
Chapitre IV : Implémentation
Page 131
Chapitre IV : Implémentation
Page 132
Chapitre IV : Implémentation
La figure 108 jointe ci-dessous représente l’interface de consultation d’un bon du trésor :
La figure 109 jointe ci-dessous représente l’interface de vérification de l’échéance d’un bon
du trésor :
Page 133
Chapitre IV : Implémentation
L’interface est séparée en deux blocs : le premier a pour rôle d’afficher une opération
de refinancement et la deuxième permet d’ajouter, modifier ou supprimer une garantie.
La figure 110 jointe ci-dessous représente l’interface de gestion de garanties crédit:
Page 134
Chapitre IV : Implémentation
Page 135
Chapitre IV : Implémentation
Page 136
Chapitre IV : Implémentation
Page 137
Chapitre IV : Implémentation
La figure 115 jointe ci-dessous représente l’interface de consultation d’un bon du trésor :
Page 138
Chapitre IV : Implémentation
Page 139
Chapitre IV : Implémentation
Page 140
Chapitre IV : Implémentation
5. Conclusion
Ce chapitre annonce la fin du cycle de développement. Malgré les contraintes
affrontées, nous avons pu réaliser une application exécutable qui assure les fonctionnalités des
cas d'utilisation définis dans les phases précédentes et prêt à transiter vers les utilisateurs de
manière itérative et incrémentale.
Page 141
Conclusion Générale
Conclusion Générale
Ce stage constitue une initiation et une prise de contact avec la vie professionnelle,
nous avons été appelées à mettre en place une application de gestion et de suivi de
contreparties de refinancement.
Notre passage par la banque centrale de Tunisie a été fructueux et très enrichissant.
En effet, ce stage nous a donné l’opportunité de mettre en pratique nos
connaissances acquises durant notre cursus universitaire, de nous familiariser avec d’autres
outils et de profiter de l’environnement professionnel et des compétences de cette
organisation par l’échange d’idées et d’informations.
Le langage de modélisation « UML »utilisé nous a permis de bénéficier de ces
niveaux de conception pour une meilleure compréhension du domaine étudié.
L’implémentation du système sous « ORACLE »s’est avérée profitable par l’usage de
nouvelles évolutions des outils de développement tels que Forms Builder et le langage
PL/SQL ainsi que pour l’exploitation des notions de réutilisation qu’ils offrent.
Le travail effectué a fait l’objet d’une analyse détaillée des besoins des utilisateurs,
de la conception et de l’élaboration d’un logiciel informatique qui prend encore plus de
fiabilité et d’efficacité.
On peut parvenir à une évolution dans le futur compte tenu du fait qu’aucun produit
n’est totalement parfait et que toute conception peut s’enrichir et évoluer. Nous proposons
que la déclaration des lignes de bon du Trésors et les encours relatifs à ces lignes sera
transmise via le système d’échange de données (SED), ce qui permet le traitement
automatique de ces déclarations et qui entraine par la suite la réduction du temps de traitement
et d’éviter les erreurs détectés lors de prise en charge manuel de ces déclarations.
Page 142
Webographie
Webographie
[1], [2] :
http://www.bct.gov.tn/ consulté le (13/02/2014)
[4] :
http://www.ouestdecision.fr/contenu/les_editeurs/fiches/fiche-produit-power-amc.htm
consulté le (20/02/2014)
[5] :
http://fr.wikipedia.org/wiki/Architecture_trois_tiers consulté le (28/02/2014)
[6] :
http://www.memoireonline.com/07/08/1225/mise-en-place-systeme-information-oracle-
architecture-trois-tiers.html consulté le (28/02/2014)
[7] :
http://uml.developpez.com/faq/?page=Cas-d-utilisation#Qu-est-ce-qu-un-acteur consulté le
(01/03/2014)
[8] :
http://support.objecteering.com/objecteering6.1/help/fr/objecteering_uml_modeler/diagrams/d
eployment_diagrams.htm consulté le (20/03/2014)
[9] :
http://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es_relationnelle consulté le (02/04/2014)
[10] :
http://fr.wikipedia.org/wiki/Toad_(logiciel) consulté le (10/04/2014)
Page 143
Bibliographie
Bibliographie
[3] : Les cahiers du programmeur uml2 - modéliser une application web –
Auteur(s) : Pascal Roques
Editeur(s) : Eyrolles
Collection : Les cahiers du programmeur
Nombre de pages : 246 pages
Date de parution : 02/10/2008 (4e édition)
EAN13 : 9782212123890
Page 144