Page | I

EPIGRAPHE

« La science restera toujours le plus beau

désir de notre nature, la curiosité ; elle fournira à
l’homme le seul moyen qu’il ait d’améliorer son
sort. »

Ernest Renans
 Page | II

DEDICASE

À tous les chercheurs dans le domaine informatique. Plus particulièrement aux

ingénieurs techniciens en Ingénierie des systèmes d’information de l’université
Protestante de Lubumbashi.
 Page | III

REMERCIEMENT

Qu’il nous soit permis de remercier en premier par ces quelques lignes de
manifester nos reconnaissances sur tout le sentiment de gratitude du fond de notre cœur
de ce travail qui sanctionne la fin de notre premier cycle de nos études supérieures à
tous ceux qui matériellement, moralement et scientifiquement nous ont assistés.

Cet avec honneur et honnêteté que je tiens à remercier mon Dieu en qui nous
croyons, lui qui est le maitre de temps est de circonstance, le rémunérateur du temps de
la fin, source de toutes intelligences et sagesses, qui nous a donné la vie et que sans lui
l’homme ne parviendra pas à aucune réalité sur la terre

Mes remerciements à cœur soie à tous les professeurs de l’Université

protestante de Lubumbashi chef des travaux et aux autorités académiques de la faculté
des sciences informatiques en particulier chapeauté par le Docteur blaise FYAMA
pour cette formation de qualité qu’il rendu disponible au travers son corps professoral
mérité et compétent qu’elle égorge, assistant et charger des cours pour tous les
enseignements bien riche et l’encadrement par leur conseils adéquat qu’ils ont fournis
tout au long de notre formation

Je voudrais exprimer ma grande reconnaissance à mes chers parents

KASONGO KILAMBE, THERESE KAMBANGE et MARCEL KILAMBE pour leur
amour, leurs conseils, leurs prières ainsi que leur soutien inconditionnel, à la fois moral
et économique sans oublier madame CARINE KALENGA, qui m'a permis de réaliser
les études que nous voulions et par conséquent ce MEMOIRE.

Nous sommes reconnaissants à l’endroit de toute la famille : PATRIKC

KILAMBE, ILDE KILAMBE, ELSA MUMBA, FRANKC KILAMBE, ESTHER
MUMBA, DAN MBUYU, SAMIELLA KILAMBE, CHARKC KILAMBE, EXAUCE
KILAMBE, Lydia NGOY sans oublier mes tantes et oncles.

À nos compagnons de lutte : RAISSA MBAMB, DAN BANZA, JEAN-LUC

NOHA, LUMIERE KATAMBA, DANIEL MBAYA. Pour votre soutien moral et
intellectuel et pour les instants passés ensemble.

Nos remerciements au Ministère d’affectation assoiffés de Dieu en

particulier le BERGER HAROLD MPIANA pour toutes les prières adressées à notre
viveur.
 Page | IV

LISTE DES FIGURES

Figure 1: les parties d'une application.............................................................15

Figure 2: architecture 1- tier............................................................................17

Figure 3:architecture 2-tiers.............................................................................18

Figure 4: architecture 3-tiers............................................................................19

Figure 5: DIAGRAMME BPMN POUR LE METIER.................................38

Figure 6: DIAGRAMME DE CAS D'UTILISATION SYSTEME...............43

Figure 7: DIAGRAMME DE SEQUENCE AUTHENTIFICATION..........46

Figure 8: DIAGRAMME DE SEQUENCE PASSER DEMANDE

DECLARATION...........................................................................................................48

Figure 9: DIAGRAMME DE SEQUENCE TAXER DECLARATION.......50

Figure 10: DIAGRAMME DE SEQUENCE PAYER DECLARATION

IMPOT............................................................................................................................52

Figure 11: DIAGRAMME ENREGISTRER BORDEREAU DE

PAIEMENT....................................................................................................................54

Figure 12 : Diagramme séquence éditer quittance.........................................55

Figure 13:Diagramme gérer profil utilisateur................................................59

Figure 14:Diagramme de classe participante Authentification.....................59

Figure 15:Diagramme de classe participante passer demande déclaration. 60

 Page | V

Figure 16: Diagramme de classe participante taxer déclaration..................61

Figure 17: Diagramme de classe participante payer déclaration impôt.......61

Figure 18:Diagramme de classe participante enregistrer bordereau de

paiement.........................................................................................................................62

Figure 19: Diagramme de classe participante éditer quittance.....................62

Figure 20:Diagramme de classe participante gérer profil utilisateur..........63

Figure 21:Diagramme d'interaction Authentification...................................64

Figure 22:Diagramme d'interaction passer demande déclaration................65

Figure 23:Diagramme d'interaction taxer déclaration..................................66

Figure 24:Diagramme d'interaction payer déclaration impôt......................67

Figure 25:Diagramme d'interaction enregistrer bordereau paiement.........68

Figure 26:Diagramme d'interaction éditer quittance....................................69

Figure 27:Diagramme d'interaction gérer profil utilisateur.........................71

Figure 28 :MLD...................................................................................................74

Figure 29Modèle physique des données...........................................................79

Figure 30 Diagramme de déploiement.............................................................81

 Page | VI

chapitre I: LISTE DES TABLEAUX

Tableau 1RECENSEMENT DES ACTEURES..............................................35

Tableau 2IDENTIFICATION DES ACTEURS SYSTEME.........................40

Tableau 3 CLASSEMENT DES CAS D'UTILISATION EN ITERATION43

 Page | VII

LISTE DES ABREVIATION

DRHKAT : direction des recettes du haut Katanga

HTML : HyperText Markup langage

CSS : Castaing style Sheets

PHP : Personale Home page

SGBD : Système de gestion de base de données

SQL : Structured Query langage

IHM: Interface homme machine

UP: Unified process

UML : Unified modeling langage

OOD : Object oriented désigne

OOSE: Object oriented software engineering

OMG: Object management croup

BPMN: Business process model and notation

XML-RPC: Remote procedure call

XML : Extensible markup langage

XAML : Extensible Application markup langages

URL : Uniforme ressource Locator

OMT : Object Modeling Technique

 Page | 8

INTRODUCTION GENERALE

Depuis le premier jour que j’avais mis mes pieds dans l’enceinte d’up le jour où les
autorités du département informatique lors de l’accueil des nouveaux venus en informatique
tout ce qu’ils disaient concernant l’informatique je m’étais dit que je devais aussi concevoir
une application qui devrait être au service des gens. Et ce qui m’a encore plu c’est
l’expérience vécut pendant mon stage j’ai constaté la manière dont s’effectuer le paiement des
impôts puis comment il y avait le risque de perdre les données comme ça se faisait sur papier
et des disputes qui n’arrêtaient de se remarquer presque tous les jours entre les contribuables
et les agents de la DRHKAT. Et je m’étais dit qu’il fallait la conception d‘une (architecture)
application qui pourrai améliorer le système existant au sein de la DRHKAT.

Ce pourquoi notre sujet porte sur « l’analyse et conception par la méthode UP d’une

architecture client / serveur de déclaration et paiement des impôts dans une entreprise
publique cas de la DRHKAT ».

Notre sujet tient au fait que la DRHKAT est une entreprise qui pourrai nous fournir les
informations dont nous avons besoin. Et est facilement accessible.

Ayant fait mon stage à la DRHKAT précisément dans le bureau informatique. Etant
étudiante en informatique de gestion j’ai trouvée nécessaire et intéressant de réaliser un travail
qui aiderai à la simplification des taches ainsi qu’à garantir la sécurité des données au sein de l
‘entreprise et faciliter le contrôle sur cette dernière.

Le choix de cette étude n’est pas le fruit du hasard. En tant que finaliste en 3eme
bachelier en informatique de gestion. Il s’agit d’une opportunité de mettre en œuvre une
application des théories de formalisation du système informatique dans le secteur pour la
bonne gestion et le bon contrôle de paiement des impôts. Pour la direction générale des
recettes du haut Katanga, la mise en place d’une application et de notre base de données
permettra de prévenir les ennuis rencontrés dans l’accomplissement des tâches liées à la
gestion et au contrôle de paiement des impôts ainsi que la perte de temps causer par
l’établissement des fiches, nous ont ainsi poussés à porter le choix sur ce sujet.
 Page | 9

Depuis quelques années, le monde subit un changement suite à une évolution à grande
vitesse dans l’utilisation et la perfection des nouvelles technologies de l’information et de la
communication qui sont actuellement visible presque dans tous les domaines de la vie.
L’informatique est actuellement utilisée dans l’entreprise et fait partie d’un système
d’information, de production.

Vue que j’étais sur terrain lors de mon stage j’assistais presque tous les jours aux
problèmes qui se causer avec le paiement des impôts manuel. Un contribuable pouvait arriver
pour faire sa déclaration de l’impôt. On lui donne la fiche pour compléter après on lui renvoie
à la banque pour verser l’argent et le contribuable se décide de ne pas passer à la banque après
quelques semaines il se pointe à la DRHKAT pour leurs dire qu’il devait effectuer la
déclaration d’un autre mois, car pour le mois passer il avait déjà payé. L’agent du bureau
d’impôt cherche la fiche dans le classeur pour voir si le monsieur avait déjà payer pourtant on
ne retrouve pas sa fiche et on lui dit qu’il n’a pas encore payer mais le contribuable insiste
d’avoir payé d’où l’agent du bureau d’impôt était obligé de chercher toutes les fiches pour
voir si le contribuable est réellement en ordre et ça pouvait prendre beaucoup des temps pour
que le calme retourne dans la salle vue qu’ils se disputaient déjà en tenant compte de tout ça
nous nous sommes posés deux questions qui feront l’objet de notre étude :

 Quelle solution pourrions-nous apporté afin de remédier aux différents

problèmes que rencontrent les utilisateurs dans le processus de déclaration et
paiement des impôts ?
 Par quelle démarche méthodologique pourrions-nous aboutir à cette solution ?

Et comme l’hypothèse étant une proposition des réponses aux questions précédentes la
problématique et ainsi nous pouvons répondre anticipativement aux questions de la
problématique comme suite :

 Nous proposons comme solution de concevoir une architecture client/serveur

de déclaration et paiement des impôts au sein de la DRHKAT.
 Pour aboutir à cette solution nous avons optés pour la méthode UP avec UML
comme langage de modélisation.
 Page | 10

L’intérêt du sujet de ce travail est de rendre optimal le processus de control de

déclaration et paiement des impôts pouvant servir de base pour un contrôle de fiche dans le
laps de temps et la conservation des données sur un support magnétique pour éviter la
volatilité des petits papiers causant la perte de certaines informations. Ce sujet nous permettra
d’analyser et de concevoir un système de déclaration et paiement des impôts qui aidera ceux
qui viendront après nous, à comprendre que l’informatique est une science en constance
évaluation. Et ce logiciel sera utile non seulement à la DRHKAT, mais aussi aux autres
établissements. Notre travail à un triple intérêt :

 Du point de vue scientifique : nous estimons que notre travail permettra à d’autres
chercheurs qui vont aller dans ce domaine tout en mettant en pratique toutes les
connaissances acquises au cours de notre formation pendant trois ans afin d’ajouter
une pierre dans la construction du monde informatique.
 Du point de vue personnel : ce travail nous permettra de découvrir ce que nous avons
pu acquérir tout au long de nos études universitaires en informatique de Gestion.
 Du point de vue social : nous estimons que notre travail permettra à l’utilisateur de
bien faire la déclaration et le paiement des impôts dans peu de temps possible tout en
étant à un endroit où il y a un réseau.

Nous ne sommes pas le premier à pouvoir parler sur ce sujet et faire des
recherches. Certes il y a d’autres personnes qui nous ont précédées et qui ont parlées
dans ce domaine. Nous sommes dans l’obligation de présenter quelques travaux
antérieurs de ceux qui nous ont précédés et l’ouvrage qui cadre avec notre sujet
d’étude pour pouvoir amener quelques pistes des solutions. Les travaux ci-dessous
nous a intéressés :

 Kilembe Landry université protestante de Lubumbashi dans son travail pour

l’obtention de diplôme de licence en informatique de gestion 2019-2020
intitulé « mise au point d’une application de paiement des vignettes
automobiles. ».
Dans son travail il s’agit de mettre en place une application pour la
gestion de paiement des vignettes. Il a mis en plus l’accent sur le paiement des
 Page | 11

vignettes en ligne ce travail converge au niveau des vignettes, mais le nôtre

d’étend plus sur la déclaration et paiement des impôts au sein de l’entreprise,
s’est-il dire on commence par l’enregistrement des données dans la base de
données afin de rendre le contrôle assez facile par la suite. Étant donné que
l’enseignement est un domaine plus vaste, notre recherche se basera sur
l’analyse et conception par la méthode UP d’une Architecture client /serveur
de déclaration et paiement des impôts, nous nous baserons seulement sur la
déclaration et le paiement des impôts. Au cours de ce projet nous allons
concevoir une Architecture client /serveur, qui sera en mesure de nous faire
ressortir les différentes rubriques pour permettre à l’agent du bureau d’impôt
de pouvoir bien faire la gestion de déclaration et paiement des impôts sans
difficulté.

Pour bien atteindre nos objectifs poursuivis nous sommes obligées d’adopter une
méthode qui est l’ensemble des opérations intellectuelles par lesquelles une discipline
cherche à étudier la vérité et qu’elles puissent les démontrer. C’est ainsi nous avons choisis
la méthode UP (Unified procession) qui est un processus de développement logiciel itératif
et incrémental ; centré sur l’architecture, piloté par les cas d’utilisations et orienté par la
diminution des risques.

Pour être plus précis nous avons choisi le langage de modélisation UML ( Unified
Modeling Langage) qui est une nouvelle méthode de modélisation et de conception
unifiant les principales méthodes orientées objet ; UML est donc une norme du langage
de modélisation objet qui a été publié, dans sa première version en novembre 1997 par
l’OMG (Object Management Group), instance de normalisation internationale du
domaine de l’objet et qui est un langage de modélisation graphique et textuel destiné à
comprendre et à décrire des besoins spécifier et documenter des systèmes, esquisser des
architectures logicielles, concevoir des solutions et communiquer des points de vues. Les
techniques sont des moyens précis pour atteindre un résultat. Tout travail scientifique doit
être soutenu par des techniques appropriées pour que les résultats des recherches soit
rationnel. Dans le cadre de notre travail nous avons opté la technique de développement
 Page | 12

logiciel, cette technique nous permettra de développer du code dans un langage de

programmation préalablement choisi.
Pour ne pas aboutir à des conditions très vagues, la rigueur scientifique nous
exige de limiter notre champ d’investigation, C’est ainsi que notre recherche est
centrée au sein de la direction générale de recettes du haut-Katanga. Cette institution
regorge en son sein plusieurs services, quant à notre niveau, nous nous baserons dans
le service générateur des fonds et des impôts.
Ainsi une démarche a été conçue pour mener les travaux et atteindre les
objectifs de ce mémoire à travers les différents chapitres qui constituent ce travail :
 Le premier chapitre porte sur la présentation de l’architecture client/serveur et
l de la méthode de conception UP
Dans ce chapitre nous passerons en revue sur l’architecture
client/serveur et la présentation de la méthode qui sera utilisée.
 Le deuxième chapitre concerne l’analyse métier sur la déclaration et paiement
des impôts à la DRHKAT
Ce chapitre consistera à présenter la direction générale des recettes du
haut-Katanga et l’analyse métier de cette dernière
 Le troisième chapitre porte sur la conception du nouveau système
d’information
Ce chapitre consistera à produire la structure du système
indépendamment des toutes contraintes et ensuite nous allons passer à la
modélisation du nouveau système.
 Le quatrième chapitre concerne le Développement d’un nouveau système pour
le processus de déclaration et de paiement
Ce chapitre nous aidera à mettre en œuvre le nouveau système pour le
processus de déclaration et de paiement
Enfin, en respectant la traduction de la rédaction scientifique, nous
atterrirons à la fin de ce travail avec une conclusion qui retracera de manière
synoptique tout le parcours du travail en revenant sur ce qui a pu être réalisé
durant nos travaux. Les objectifs atteints par le travail, les réalisations et
l’apport du présent travail.
 Page | 13

CHAPITRE I:  PRESENTATION DE L’ARCHITECTURES

CLINT/SERVEUR ET DE LA METHODE UP

Introduction

Dans ce chapitre, nous parlerons de la conception d’une architecture client –serveur,

de comment est sa conception, son fonctionnement sans oublier les sortes ou types
d’architectures existants et des clients qui peuvent intégrer dans les interactions. Pour finir
nous verrons aussi la méthode UP.

I.3 CONCEPTION DES ARCHITECTURES LOGICIELS

L’architecture client-serveur s’articule autour d’un réseau auquel sont connectés deux
types d’ordinateurs le serveur et le client. Le client et le serveur communiquent via des
protocoles.

Les applications et les données sont réparties entre le client et le serveur de manière à
réduire les couts.

Le client-serveur représente un dialogue entre deux processus informatiques

par l’intermédiaire d’un échange de message. Cela signifie que des machines clients
(machines faisant partie du réseau) se mettent en contact avec un serveur, une machine
généralement très puissante en termes de capacités d’entrées- sorties qui leur fournit des
services. Lesquels services sont exploités par des programmes, appelés programmes clients,
s’exécutant sur les machines clients.
 Page | 14

Le Web constitue l’application client- serveur la plus répandue dans le monde. Ce

nouveau modèle client-serveur est constitué des clients légers universels ; les navigateurs qui
communiquent avec des serveurs web de plus en plus sophistiqués.

Les applications Web de la première génération sont très simples et se contentent

dans leur version initiale de servir des pages HTMAL statique et en lecture seule. Les
documents situés sur les serveurs sont accessibles au moyen des liens hypertexte qui mettent
en œuvre des mécanismes de nommages universels au travers des URL (Uniforme Resource
Locator).

Localisation des documents s’effectue en 2 temps : une étape consacrée à la recherche

du serveur par le mécanisme DNS, puis une recherche du document sur le serveur.

Le Web que nous connaissons aujourd’hui ne se contente plus de diffuser de

l’information électronique à caractère statique. Il constitue une plate-forme applicative client-
serveur réellement interactive. Sa dernière évolution intègre, notamment dans le domaine de
l’intranet et du commerce électronique, des technologies de composants répartis.

I.4 ENVIRONNEMENT CLIENT SERVEUR

I.4.1 Serveur

Un serveur est un programme qui offre un service sur le réseau. Le serveur

accepte des requêtes, les traites et renvoie le résultat au demandeur. Une requête est un appel
de fonction, la réponse éventuelle pouvant être synchrone ou asynchrone (le client peut
émettre d’autres requêtes sans attendre) Les arguments et les réponses sont énoncés dans un
protocole. Le terme serveur s’applique à la machine sur lequel s’exécute le logiciel serveur.
Pour pouvoir offrir ces services en permanence, le serveur doit être sur un site avec accès
permanent il doit s’exécuter en permanence.

I.4.2 CLIENT

C’est la description du fonctionnement coopératif entre le serveur et le client. Les

services internes sont conçus selon cette architecture. Chaque application est composée de
logiciel serveur et logiciel client. A un logiciel serveur, peut correspondre plusieurs logiciels
 Page | 15

clients développés dans différents environnements : UNIX, Mac, PC… La seule obligation
est le respect du protocole entre les deux processus communicants. Ce protocole étant décrit
dans un RFC (Requeste For Comment). L’architecture client-serveur s’appuie sur un poste
central, le serveur, qui envoi des données aux machines clients. Des programmes qui accèdent
au serveur sont appelés programmes clients (client FTP, client mail, navigateur).

I.4.3 LES ARCHITECTURES

En informatique les applications peuvent être découpées en trois niveaux

d’abstractions distincts, dans la règle générale nous avons :

 La couche de présentation : Dite IHM (interface homme machine) qui permet

l’interaction de l’application avec l’utilisateur. Cette dernière gère les saisies au
clavier, à la manipulation de la souris ainsi que la présentation (affichage) des
informations à l’écran. Epandent elle devrait être conviviale et ergonomique.
 La couche applicative : elle décrive les travaux à réaliser par l’application et ces
travaux peuvent toutefois être découpés en deux familles :
o Les traitements locaux, qui regroupent les contrôles effectués au niveau du
dialogue avec IHM visant essentiellement le contrôle et l’aide à la saisie.
o Les traitements globaux, qui constituent l’application elle- même, cette
couche est appelée couche métier. Contient les règles internes qui régissent
l’application.
 Les données : on parle aussi d’accès aux données, qui regroupent l’ensemble de
mécanismes permettant la gestion des informations stockées par l’application.
 Page | 16

Figure 1: les parties d'une application

Ces trois niveaux peuvent être imbriqués ou reparties de différentes manières entre
plusieurs machines physiques. Le noyau de l’application est composé de la logique de
l’affichage et logique des traitements. Le découpage et la répartition de ce noyau permettent
de distinguer les architectures applicatives suivantes : l’architecture à 1 niveau, l’architecture
à 2 niveaux, l’architecture à 3 niveaux ainsi que l’architecture à N niveaux.

I.5 NIVEAU D’ABSTRATION D’UNE APPLICATION

Les 3 niveaux peuvent être imbriqués ou répartis de différentes manières entre

plusieurs machines physiques ou logiques Suivant les contraintes d’utilisation ou contraintes
techniques

I.5.1 ARCHITECTURE un-tiers

C’est une architecture dont les 3 couches applicatives s’exécutent sur la même
machine on parle d’informatique centralisée : contextes multi-utilisateurs dans le cadre d’un
site central.

Cette architecture présentée des avantages comme la fiabilité des solutions sur site
central qui gère les données de façon centralisée ; l’interface utilisateur moderne des
applications. Au-delà des avantages elle a fait preuve des limites ou l’interface utilisateur en
 Page | 17

mode caractères et la cohabitation d’application exploitant des données communes peu fiable
au-delà d’un certain nombre d’utilisateurs.

Epandent il faille trouver une solution conciliant les avantages de cette architecture.

Pour y arriver il a fallu scinder les applications en plusieurs parties distinctes et

coopérâtes : la gestion centralisée des données et la gestion locale de l’interface utilisateur.

Figure 2: architecture 1- tier

I.5.2 ARCHITECTURE à 2-tiers

Ce type d’architecture (twa-tier architecture en anglais) caractérise les systèmes

client-serveur pour lesquels le client demande une ressource et le serveur la lui fournit
directement, en utilisant ses propres ressources. Cela signifie que le serveur ne fait pas appel à
une autre application afin de fournir une partie du service.

La gestion des données est en charge par un SGBD centralisé, s’exécutant le plus
souvent sur un serveur dédié. Ce dernier est interrogé en utilisant un langage de requête qui
est le SQL

Le dialogue entre client et serveur se résume à l’envoi de requête et au retour des

données correspondant aux requêtes, ce dialogue nécessite l’instauration d’une
communication entre client et serveur.
 Page | 18

Cette architecture offre des avantages dans le fait que l’interface utilisateur est riche
et de l’appropriation des applications par l’utilisateur. Cette dernière aussi des limites dans la
charge du poste qui était importante, qui supporte la grande majorité des traitements
applicatifs ; la maintenance et la mise à jour difficile à gérer et la difficulté de modifier
l’architecture initiale.

Figure 3:architecture 2-tiers

I.5.3 ARCHITECTURE à 3-tiers

Dans cette architecture (three-tier architecture en anglais), existe un niveau

supplémentaire : client (l’ordinateur demandeur de ressources) équipé d’une interface
utilisateur (généralement un navigateur Web) chargé de la présentation. Un serveur
d’application (appelé middleware) qui fournit la ressource, mais en faisant appel à un autre
serveur. Un serveur de données qui fournit au serveur d’application les données requises pour
répondre au client. Il existe un niveau intermédiaire, c’est –à-dire que l’on a généralement une
architecture partagée entre :

1. Un client, c’est-à-dire l’ordinateur demandeur des ressources, équipées

d’une interface utilisateur (Généralement un navigateur Web) chargée de
la présentation ;
 Page | 19

2. Le serveur d’application (appelé également middleware), chargé de

fournir la ressource mais faisant appel à un autre serveur
3. Le serveur de données, fournissant au serveur d’application les données
dont il a besoin.

Figure 4: architecture 3-tiers

I.5.4 Comparaison des deux types d’architecture

L’architecture à deux niveaux est donc une architecture client/serveur dans

laquelle le serveur est polyvalent, c’est-à-dire qu’il est capable de fournir directement
l’ensemble des ressources demandées par le client. Dans l’architecture à trois niveaux par
contre les applications au niveau serveur sont délocalisées, c’est-à-dire que chaque serveur est
spécialisé dans une tâche (serveur Web/serveur de base de données par exemple).
L’architecture à trois niveaux permet :

 Une plus grande flexibilité/souplesse ;

 Une sécurité accrue car la sécurité peut être définie indépendamment pour chaque
service, et à chaque niveau ;
 De meilleures performances, étant donné le partage des tâches entre les différents
serveurs.
 Page | 20

I.5.5 ARCHITECTURE à N-tiers

Une architecture à N –tiers est un modèle en couche dans lequel chaque couche
communique seulement avec ses couches adjacentes(supérieure et inférieure) et le flux de
contrôle traverse le système de haut en bas ;les couches supérieures contrôlent les couches
inférieures, c’est-à-dire, que les couches supérieures sont toujours sources
d’interaction(clients) alors que les couches inférieures ne font que répondre à des requêtes
(serveurs), l’architecture peut être étendue sur un nombre de niveaux plus important : on parle
dans ce cas d’architecture à N niveaux (ou multi-tiers).

I.6 Caractéristique des systèmes client/serveur

Les éléments qui caractérisent une architecture client/serveur sont :

1. Service : Le modèle client/serveur est une relation entre des processus qui tournent
sur des machines séparées. Le serveur est un fournisseur de service. Le client est un
consommateur de service.
2. Partage des ressources : Un serveur traite plusieurs clients et contrôle leurs accès aux
ressources.
3. Protocole asymétrique : Conséquence du partage de ressource, le protocole de
communication est asymétrique le client déclenche le dialogue ; le serveur attend les
requêtes des clients.
4. Transparence de la localisation : L’architecture client/serveur doit masquer au client la
localisation du serveur (que le service soit sur la même machine ou accessible par le
réseau). Transparence par rapport aux systèmes d’exploitation et aux plates-formes
matérielles. Idéalement, le logiciel client serveur doit être indépendant de ces deux
éléments.
5. Message : Les messages sont les moyens d’échanges entre client et serveur.

I.7 TYPE DES CLIENTS

Un logiciel client est un programme qui utilise le service offert par un serveur. Le
client envoie une requête et reçoit la réponse. Il peut être raccordé par une liaison temporaire.
 Page | 21

I.7.1 Client léger

Le terme « client léger » (parfois « client pauvre », en anglais « tin client »), par

opposition au client lourd, désigne une application accessible via une interface Web (en
HTML) consultable à l’aide d’un navigateur Web, ou la totalité du logique métier est traité du
côté du serveur. Pour ces raisons, le navigateur est parfois appelé client universel. L’origine
du terme lui-même provient de la pauvreté du langage HTML,

Qui ne permet de faire des interfaces relativement pauvres en interactivité, si ce n’est

pas le biais du langage JavaScript. Le fait que l’essentiel des traitements soit réalisé du côté
serveur et que l’interface graphique est envoyée au navigateur à chaque requête permet une
grande souplesse de mise à jour. En contrepartie, l’application doit s’affranchir des différentes
interprétations du code HTML par les différents navigateurs et l’ergonomie de l’application
présente un champ réduit.

I.7.2 Client lourd

Le terme « client lourd » en anglais « fat client » ou « Healy client »), par

opposition au client léger, désigne une application cliente graphique exécutée sur le système
d’exploitation de l’utilisateur. Un client lourd possède généralement des capacités de
traitement évoluées et peut posséder une interface graphique sophistiquée. Néanmoins, ceci
demande un effort de développement et tend à mêler la logique de présentation (l’interface
graphique) avec la logique applicative (les traitements). Ce type d’application étant
généralement installé sur le Système d’exploitation de l’utilisateur, une nouvelle version doit
être installée afin de la faire évaluer. Pour y remédier, les éditeurs d’applications lourds les
dotent généralement d’une fonctionnalité exécutée au lancement de l’application, permettent
de vérifier sur un serveur distant si une version plus récente est disponible et le cas échéant
propose à l’utilisateur de la télécharger et de l’installer.

I.7.3 Client riche

Un « client riche » est un compromis entre le client léger et le client lourd. L’objectif
du client riche est donc de proposer une interface graphique, décrite avec une grammaire de
description basée sur la syntaxe XML, permettant d’obtenir des fonctionnalités similaires à
celles d’un client lourd (glisser déposer, onglets, multi fenêtrage, menus déroulants). Les
 Page | 22

clients riches permettent ainsi de gérer l’essentiel des traitements du côté du serveur. Les
données sont ensuite transmises dans un format d’échange standard utilisant la syntaxe XML
(SOAP ; XMLRPC), puis interprétées par le client riche. Les principaux standards permettant
de définir une application riche sont les suivants :

 XAML (extension application Markup Langage), prononcer « Dammel », un

standard XML proposé par Microsoft, utilisé notamment dans les applications
utilisant le Framework.
 XUL, prononcez « zool. », un standard XML proposé par la fondation
Mozilla, utilisé par exemple dans le client de messagerie Mozilla Thunderbird
ou dans le navigateur Mozilla Firefox ;

I.8 LA REPARTITION DES TACHES

Dans l’architecture client –serveur, une application est constituée de trois parties :

 L’interface utilisateur
 La logique des traitements
 La gestion des données

Le client n’exécute que l’interface utilisateur (souvent une interface graphique) ainsi
que la logique des traitements (formuler la requête), laissant au serveur de bases de données.
La gestion complète des manipulations de données la liaison entre le client et le serveur,
correspond à tout un ensemble complexe des logiciels appelés middleware qui se chargent de
toutes les communications entre les processus.

I.9 LES DIFFERENTS MODELES DE CLIENT/SERVEUR

En est fait les différences sont essentiellement liées aux services qui sont assurés par
les serveurs. On distingue couramment :

I.9.1 LE CLIENT-SERVEUR DE PRESENTATION

Dans ce cas la présentation des pages affichées par le client est intégralement prise en
charge par le serveur. Cette organisation présente l’inconvénient de générer un trafic réseaux.
 Page | 23

I.9.2 LE CLIENT-SERVEUR TRAITEMENT

Dans ce cas, le serveur effectue des traitements à la demande du client. Il peut

s’agir de traitement particulier sur des données, de vérification de formulaire de saisie, de
traitements d’alarmes

Ces traitements peuvent être réalisés par des programmes installés sur des serveurs
mais également intégrés dans les bases de données, dans ce cas, la partie donnée et traitement
sont intégrés.

I.9.3 LE CLIENT-SERVEUR DES DONNEES

Dans ce cas, le serveur assure des taches de gestion, stockage et de traitement de

données. C’est le cas le plus connu de client- serveur est utilisé par tous les grands SGBD :

La base de données avec tous ses outils (maintenance, sauvegarde …) est installée sur
un poste serveur. Sur les clients, un logiciel d’accès est installé permettant d’accéder à la base
de données du serveur tous les traitements sur les données sont effectués sur le serveur qui
renvoie les informations demandées par le client.

I.10 AVANTAGES ET INCOVENIENTS

I.10.1 AVANTAGES

 Unicité de l’information : toutes les données sont stockées sur un même serveur
 Meilleure sécurité : simplification des contrôles de sécurité y compris pour la mise à
jour et la mise à jour centralisé aussi bien des données et logiciels.
 Meilleure fiabilité : En cas de panne, seul le serveur fait l’objet d’une réparation.
 Facilité d’évolution : architecture d’évolutive, il est très facile de rajouter ou
d’enlever des clients ou des serveurs.

I.10.2 INCOVENIENTS

 Un cout d’exploitation élevé (bande passante, câbles, ordinateurs surpuissants)

 En cas de panne du serveur, plus aucun client n’a accès aux informations
 Page | 24

 Si trop des clients veulent communiquer avec le serveur ce dernier risque de ne pas
supporter la charge

SECTION 2 PRESENTATION DE LA METHODE UP

La méthode d’analyse orientées objet sont initialement issues des milieux

industriels.

La préoccupation dominante de leurs auteurs est le génie logiciel, c’est-à-dire les

principes et la technique permettent d’augmenter la rigueur et la qualité quand on construit
une application informatique. Initialement, UML (Unifed Modeling Langage) est le résultat
de la fusion de trois méthodes orientées objet.

La méthode OOD, objet oriented desing, de grady booch a été conçue à la

demande du ministère de la défense des États-Unis. L’objectif était de préparer de façon
rigoureuse la structuration des programmes écrits en langage ADA ou C++.

La méthode OMT objet modeling technique de James Rumbaugh en 1996 a été

mise au point à général électrique. Ses auteurs ont été largement influencés par les
applications

D’informations industrielles (automates, contrôle de processus…) En plus des

principes des langages à objet, ils ont été inspirés par les techniques de modélisation
conceptuelle des méthodes d’analyse des années 1980.

La méthode OOSE, objet oriented software engineering d’IVAR Jacobson en

1993 est d’origine universitaire (informatique temps réel) et industrielle. Comme OMT, la
méthode a emprunté aux méthodes d’analyse antérieures la technique de modélisation
conceptuelle, enrichie des aspects comportementaux. Son originalité consiste à faire reposer
l’analyse sur l’expression par l’utilisateur de la façon dont il pense utiliser le futur système.
 Page | 25

I.11 UNIFIED MODELING LANGAGE (UML)

I.11.1 Définition de l’UML

C’est un langage de modélisation graphique à base de pictogrammes, conçu pour

représenter, spécifier les artefacts de systèmes logiciels, de plus il est destiné à comprendre et
décrire des besoins spécifiques et documentés de systèmes, esquissé des architectures
logicielles, concevoir des solutions et communiquer des points de vue, comme il peut être
appliqué à toutes sortes de systèmes ne se limitant pas au domaine informatique. UML résulte
de l’unification de techniques ayant fait leurs preuves pour l’analyse et la conception de
grands logiciels et de systèmes complexes.

 UML est une norme

Il est nécessaire qu’une méthode objet soit définie de manière rigoureuse et

uniquement afin de lever les ambiguïtés. De nombreuses méthodes objet ont été définies, mais
aucune n’a su s’imposer en raison du manque de standardisation. C’est pourquoi l’ensemble
des acteurs du monde informatique a fondé en 1989 l’OMG (Object Management Group), une
organisation à but non lucratif, dont le but est de mettre au point des standards garantissant la
compatibilité entre des applications programmées à l » aide de langages objet et fonctionnant
sur des réseaux hétérogènes (de différents types),

A partir de 1997, UML est une norme de l’OMG, ce qui lui a permis de
s’imposer en tant que méthode de développement objet et être reconnue et utilisée par des
nombreuses entreprises.

 UML est un langage de modélisation objet

UML comble une lacune importante des technologies objet, il permet d’exprimer,
d’élaborer et de modéliser au sens de la théorie des langages, de ce fait il contient les éléments
constitutifs de ce dernier : concepts, une syntaxe et une sémantique.
 Page | 26

 UML décrit un méta modèle

La puissance et l’intérêt d’UML est normalise la sémantique des concepts qu’il

véhicule, il repose sur un méta modèle pour permettre à n’importe qui de déchiffrer son
intention de manière non équivoque, il est donc primordial de s’accorder sur la sémantique
des éléments de modélisation, bien avant de s’intéresser à la manière de les présenter.

I.11.2 Point fort d’UML

Il permet ainsi :
 Un gain de précision
 Un gage de stabilité
 L’utilisation d’outils

Il cadre l’analyse et facilite la compréhension de représentation abstraites complexes.

Son caractère polyvalent et sa souplesse en font un langage universel.

I.11.3 Point faibles d’UML

 La mise en pratique d’UML nécessite un apprentissage et passe par une période

d’adaptation
 L’intégration d’UML dans un processus n’est pas triviale, et améliorer un processus
est une tâche complexe et longue

I.12 PROCESSUS UNIFIE(UP)

I.12.1 Définition du processus unifie

UP est un ensemble de principes génériques pouvant être adaptés en fonction

des spécificités des projets. Un tableau comparatif des implémentations célèbres d'UP est
présenté en annexe (Annexe 1).

Le processus unifié est un processus de développement logiciel itératif,

centré sur l’architecture, piloté par des cas d’utilisation et orienté vers la diminution des
risques. C’est un patron de processus pouvant être adaptée à une large classe de systèmes
logiciels, à différents domaines d’application, à différents types d’entreprises, à différents
niveaux de compétences et à différentes tailles de l’entreprise.
 Page | 27

I.12.2 Les caractéristiques du processus unifie

Le Processus Unifié est une méthode de développement logiciel ayant les

caractéristiques suivantes :

A. UP est itératif et incrémental

Le projet est découpé en itérations ou étapes de courte durée qui permettent de mieux
suivre l’avancement globale. A la fin de chaque itération une partie exécutable du système
finale est produite, de façon incrémentale (par ajout).

Une itération désigne la succession des étapes de l'enchaînement d’activités, tandis

qu'un incrément correspond à une avancée dans les différents stades de développement

B. UP est centré sur l’architecture

Tout système complexe doit être décomposé en partie modulaire afin d’en faciliter la
maintenance et l’évolution ? Cette architecture (fonctionnelle, logique, matérielle, etc.) doit
être modéliser en UML, et pas seulement documentée en texte.

L’architecture d'un système logiciel peut être décrite comme les différentes vues
du système qui doit être construit ;

AVANTAGES D’UN PROCESSUS ITERATIF CONTROLE

 Permet de limiter les couts, en termes de risques aux strictes dépenses liées à une
itération
 Permet de limiter les risques de retard de mise sur le marché du produit développé
(identification des problèmes dès les premiers stades de développement et non en
phase de test comme avec l’approche « classique ».
 Permet d’accélérer le rythme de d » développement grâce à des objectifs clairs et à
court terme
 Permet de prendre en compte le fait que les besoins des utilisateurs et les exigences
correspondantes ne peuvent être intégralement définis à l’avance et se dégagent peu
à peu des itérations successives
 Page | 28

 L’architecture fournit la structure qui servira de cadre au travail effectué au cours des
itérations, tandis que les cas d’utilisation définissent les objectifs et orientent le
travail de chaque itération. Il ne faut donc pas mésestimer l’un des trois concepts.

C. UP EST PILOTE PAR LES CAS D’UTILISATIONS

Les cas d'utilisation illustrent, détectent puis décrivent les besoins
fonctionnels et leur ensemble constitue le modèle de cas d'utilisation qui dicte les
fonctionnalités complètes du système ;
Le but principal d’un système d’informatique est de satisfaire les besoins des
clients. Le processus de développement sera donc accès sur l’utilisateur.

D. UP EST ORIANTE VERS LA DIMINITION DES RISQUES

Les risques majeurs du projet doivent être identifiés au plus tôt mais surtout
levés le plus rapidement. Les mesures à prendre dans ce cadre déterminent l’ordre
des itérations

Le découpage du projet en sous-projet permet de diminuer les risques majeurs,

ou le passage dans chaque itération traite en priorité les risques majeurs.

Le cycle de développement du Processus Unifié organise les tâches et les itérations en

quatre phases.

 La phase d’initiation ou l’analyse des besoins : c’est une phase qui donne la vision
sur le projet en mettre place, sa portée, sa faisabilité en termes de cout afin de pouvoir
décider aux mieux de sa poursuite.
 La phase d’Elaboration : à ce niveau, on développe de façon incrémentale
l'architecture du noyau, les risques et la plupart des besoins sont identifiés ;
 La phase de Construction : cette phase consiste à la construction des sous-
ensembles exécutables et stables du produit final ;
 Transition : dans cette phase on procède au déploiement du système sur des sites
opérationnels
 Page | 29

Les activités du processus unifié

Les activités de développement logiciel sont reparties en cinq disciplines

fondamentales qui sont :

Capture des exigences : c’est une activité d’expression de besoins des utilisateurs
auprès de l’informaticien ou développeur.

Analyse : c’est une activité qui est porté sur la construction d’un modèle du
monde réel, qui met en évidence les propriétés importantes du problème, afin de comprendre
les besoins et les exigences des utilisateurs.

Conception : elle se rapporte aux prises de décision concernant l’architecture

d’ensemble du système à mettre en œuvre.

Implémentation : elle consiste à l’écriture des programmes dans un langage de

programmation bien déterminé.

Teste : elle permet de valider le fonctionnement de traitement en vérifiant

l’exactitude de tout le résultat produit en fonction des entrées d’une part et des sorties et des
sorties de l’autre part et de valider la logique de l’application.

COMPARAISON ENTRE BPMN ET UML

UML est le standard utilisé dans la modélisation de la plupart des aspects logiciel et
métier, le BPMN est le standard utilisé uniquement dans la modélisation des processus métier.
UML 2.5 en sa version béta est constitué de 14 diagrammes, BPMN n’en propose qu’un seul
très proche du diagramme d’activités.
 Page | 30

CHAPITRE II: ANALYSE METIER SUR LE PAIEMENT DES

IMPOTS AU SEIN DE LA DRHKAT

Avant de concevoir un système informatique, il est souvent pratique de détruire

par une étude préalable du cadre du travail, en vue d’avoir une idée générale sur le système
existant ce qui emmènera à la solution pour la mise en place du nouveau système. C’est ainsi
que ce présent chapitre consiste à la présentation de la DRHKAT.

2.1. PRESENTATION DE LA DRHKAT

La direction de ressources du haut Katanga est une des ressources importantes,

sure et intarissable du financement des charges publiques et le paiement des impôts et taxes
par les habitants de son territoire. Conformément à la constitution du 18 /02/2006 telle que
modifié par la loi n° 11/002 du 20 janvier 20011. Ce service regorge en son sein différentes
directions, bureaux, centres et cellules.

2.1.1 Création

Créée par l’Arrêté Provincial n°2016/00014/HAUT-

KATANGA du 18 Février 2016, portant création, organisation et fonctionnement de la
Direction des Recettes du Haut-Katanga, DRHKAT en sigle.

La Direction des Recettes du Haut-Katanga est un Service Provincial, sous la tutelle

du Ministre Provincial ayant les finances dans ses attributions, doté d’une personnalité
juridique et d’une autonomie administrative et financière.

2.1.2 SITUATION GEOGRAPHIQUE

Le Direction de ressources du haut Katanga (DRHKAT) en siège est situé au

centre-ville de Lubumbashi, chef-lieu de la province du haut Katanga, en république
démocratique du Congo, précisément au croisement de l’avenue KAMBOVE et MAMA
YEMO et KAPENDA dans le sous-sol du bâtiment cadastre Lubumbashi.
 Page | 31

2.1.3. MISSION DE LA DRHKAT

La DRHKAT exerce toutes les missions et prérogatives en matière des Recettes

du Haut Katanga à caractère national ainsi que des Recettes fiscales, non fiscales et droites
revenant à la province du Haut Katanga sur toute son étendue, donc la mobilisation des
recettes de la province. Du et autres revenant à la province du Haut Katanga.

Voici les missions de la DRHKAT :

 L’assiette, le contrôle, le recouvrement et le contentieux de l’impôt provincial et local

 Le contrôle, l’ordonnancement, le recouvrement et le traitement de contentieux des
recettes non fiscales.
 Le suivi et la tenue de statistique des recettes à caractère nationale et celle circulaires
et de décision à la matière.
 De recouvrir les différents types d’impôt au près du contribuable.

2.2. L’ANALYSE DE L’EXISTANT

L’analyse de l’existant est la prise de connaissance du domaine d’application et

du diagnostic des points forts et points faibles permettant une approche du problème.

C’est dans cette optique que nous sommes descendus sur terrain pour inspecter
intelligemment notre cadre d’étude, afin de fournir ou de dénicher les points à améliorer et en
vue d’apporter une nouvelle piste de solutions à cette grande institution.

La DRHKAT gérant en son sein plusieurs services générateurs des fonds et des
taxes, nous avons de notre part focalisé notre domaine d’application sur le paiement des
impôts de cette institution.

2.2.1. STRUCTURE ORGANISATIONNELLE

Nous voici au point de l’étude de l’organisation interne de la Direction des

Recettes du Haut Katanga, ici nous allons voir comment est structurée cette société, en suite
nous passerons à l’étude des fonctionnalités.
 Page | 32

La structure de la DRHKAT est subdivisée en Divisions, Bureaux, centres et cellules

L’administration centrale est composée de :

- La Direction ;
- La Division de l’administration et des Finances ;
- La Division de l’inspection ;
- La Division de gestion des impôts Provinciaux et Locaux ;
- La Division de Gestion des Recettes non Fiscale ;
- La Division du suivi ;
- La Division du Recouvrement.

2.2.1.1 FONCTIONNEMENT DE LA DRHKAT

La Direction des Recettes du Haut Katanga est dirigée par un DIRECTEUR

nommé et le cas échéant, relevé de ses fonctions par le gouverneur de la province sur
proposition du ministre provinciale ayant les finances en ses attributions après la délibération
du conseil provincial des Recettes du Haut Katanga, à ce titre, il dispose de tous les pouvoirs
nécessaires pour l’accomplissement des tâches dévolues à la direction. En cas d’absence ou
l’empêchement, l’intérim du Directeur est assuré par un chef de division désigné par le
ministre provincial ayant les finances dans les attributions sur proposition du directeur.

La Direction des Recettes du Haut Katanga est subdivisée en divisions, bureaux,

centres et cellules.
 Page | 33

2.2.1.2. DIFFERENTS IMPOTS PROVINCIAUX ET LOCAUX

 L’Impôt Foncier est payé par le titulaire du droit de propriétés, de possession,

d’usufruit ainsi que par les personnes occupant en vertu d’un bail des biens
immobiliers du domaine privé de l’état, de la province, des villes et communes.
 Impôt sur le Revenus Locatifs payé par le bailleur par l’intermédiaire du
Locataire par les Retenues sur les loyers (20%) d’une part et d’autre part par le
Bailleur lui-même le solde (2%) soit un taux de de 22%
 Impôt Réel sur les véhicules et la taxe spéciale de circulation routière sont
payés simultanément par tout propriétaire (personne physique ou morale) utilisant
un ou plusieurs véhicules sur la voie publique.

SECTION 2 MODELISATION METIER

1.7 DESCRIPTION TEXTUELLE ET FORMMELLE DU PROCESSUS
Le processus de vente des impôts à la direction des recettes du haut-
Katanga ; pour être en ordre le client doit passer par la direction pour avoir une
fiche de déclaration sur laquelle il doit remplir le formulaire et aller verser
l’argent à la banque la banque lui donne une note de perception puis retourner
à la DRHKAT pour que la DRHKAT remplit sur la note de perception et met
la signature.
1.8 DECRIPTION DES DOCUMMENTS
a. NOTE DE TAXATION
- Nom contribuable
- Redevable
- Période
- Montant
- N° enregistrement
- Délivrée
b. Impôts fonciers £ Locatif
-redevable
-type
-personne physique
 Page | 34

-personne morale
-maison utilisée
-villa
-appartement
-terrain
-étage
-autre
-total
-taux en CDF
c. Impôt réel
-catégorie
-impôt
-TSCR

-total en USD
D. FICHE DE DECLARATION
1. Identification du contribuable
- Nom
- Post nom
- Prénom
- Rang social
2. Réservé à l’administration
- Date de dépôt
- Date de vérification
- Identité et signature du vérificateur
- Référence et date d’émission de l’AMR (*)
- Référence et date démission de la note de
perception
3. Paiement
- Date
- Montant banque
 Page | 35

- Référence de la preuve de paiement

4. Détails des propriétés
- Nature du bien
- Adresse (numéro, avenue et quartier)
- Commune
- Rang de la localité
- Usage
- Superficie imposable (en m²)
- Taux
- Montant de l’impôt
 Page | 36

RECENSEMENT DES ACTEURS

Un acteur st une personne morale ou physique ou un poste de travail
qui joue un rôle dans l’organisation.

N° NOM DES TYPES SIGNIFICATION

ACTEURS

1 CONTRIBUABLE EXTERNE Cherche à payer l’impôt

2 Le réceptionniste INTERNE Ecoute le problème du

contribuable et le conduit dans le
bureau impôts au près du chef de
bureau

3 Le chef de bureau INTERNE La DRHKAT donne le papier

de la déclaration pour compléter les
éléments indiqués puis à la fin il doit
enregistrer en donnant la note de
taxation

4 La Banque EXTERNE La banque reçoit l’argent du

contribuable
 Page | 37

Tableau 1RECENSEMENT DES ACTEURES

DIAGRAMME BPMN

BPMN (Business procès Mödling and notation) de l’OMG (objet Management group)
est une notation graphique standardisée portant sur la modélisation des processus métier. Elle
vise à fournir une notation facilement compréhensible par les utilisateurs métiers (y compris
les analyses métiers, les développeurs et ceux qui devront gérer et surveiller les processus
après leur mise en œuvre) mais aussi à créer une passerelle standardisée pour combler le vide
entre la modélisation de processus métiers et les langages d’exécution métier. L’objectif du
BPMN est de fournir un cadre permettant de décrire un processus d’une manière commune à
tous les utilisateurs et ce, indépendamment de l’outil utilisé. On retrouve, au sein de la
notation BPMN 2.0, quatre t’équarris de diagrammes afin de représenter les différentes
perspectives d’un processus.

1. Les diagrammes d’orchestration (processus privé et processus public)

2. les diagrammes de collaboration

3. le diagramme de chorégraphie

4. le diagramme de conversation

Pour notre travail nous présentons juste le diagramme de

collaboration, ils suffiront pour présenter le processus métier.
 Page | 38

BPEL BPEL20 Model

Demande de Remplir Payer Reçoit note Remettre

Payer Fournir Départ Retour Fournir
déclaration fiche de montant de note de
impot informations contribuable informations Note
contribuable déclaration perception
Contribuable

perception taxation
livrée

Objet de la Conduire
visite contribuable
Réceptioniste

Contribuable
n'existe pas
Demande
Effectuer informations Enregistrer
déclaration Vérifer contribuable Demande
Vérifier Informations Donner
DRHKAT

Revenir après d'informations Reçoit note Remplir Enregistre Livrer note

impot information Contribuable informations vérifiées fiche de
un jour de note de contribuable taxation
contribuable existe déclaration perception taxation
Chefdebureau

Recevoir Remettre
montant note de
perception
BANQUE
 Page | 39

Figure 5: DIAGRAMME BPMN POUR LE METIER

 A. POINTS FORTS
-une bonne organisation de travail ;
-une bonne collaboration entre les agents ;
-ils organisent aussi les séances de formation.

B. POINTS FAIBLES

Leur travail est fait sans automatisme, c’est ainsi que nous avons
constatées que les actions mauvaises suivies des informations à la Direction de recette du
haut-Katanga suivant :

- La lenteur dans l’établissement des documents

- La mauvaise gestion des informations
- Circulation des informations à la main

C.PROPOSITION DE LA SOLUTION

Pour toutes ces remarques faites précédemment au sein de la DRHKAT ça nous a fait
beaucoup réfléchie pour :

- L’utilisation des ordinateurs sur tous les postes de travail est

nécessaire, pour permettre un bon stockage et conservation des
données afin d’éviter toute falsification des données ;
- Création d’une application plus performante qui sera en
collaboration directe avec la base de données.
 | 41

chapitre II: CONCEPTION DU NOUVEAU SYSTÈME

D’INFORMATION PASSY soft

I.1 Conception logique

Le processus de modélisation vise à obtenir une solution acceptable du système

informatique. La solution finalement retenue n’est pas obtenue en une seule itération,
plusieurs étapes sont nécessaires ; ces étapes successives permettent de raffiner le niveau de
détails du système à réaliser. Ainsi, elle permet donc de spécifier le système à réaliser, de
valider le modèle vis-à-vis des clients, de fournir un guide pour la construction du système,
qui permet d’organiser les structures de données, et de documenter le système et les décisions
prises.

Tout au long de ce chapitre, nous présenterons différents diagrammes qui concourent

à la modélisation de notre système. Ensuite nous présenterons différentes solutions en réponse
aux besoins réels exprimés par le cas d’application. Nous procèderons, sur base de certains
critères, par une comparaison des différentes solutions pour retenir celle que nous allons
implémenter.

I.2 Spécifications des besoins

I.2.1 Les besoins fonctionnels
Les besoins fonctionnels représentent les fonctionnalités du système, ils répondent
ainsi aux points précis de la problématique. Ils sont :

▪ Collaboration distante des contribuables et la DRHKAT,

▪ Consulter facilement le catalogue de la DRHKAT pour les sources des
contribuables,
▪ Gérer en temps réel de manière sure et sécurisée les payements des
contribuables.
I.2.2 Les besoins non fonctionnels

Les besoins non fonctionnels sont des besoins optionnels ou des contraintes liées à
l’implémentation et à l’interopérabilité générale du système. Il s’agit ici, notamment de :
 | 42

▪ Sécuriser l’accès à l’application,

▪ Présenter une ergonomie facile d’utilisation,
▪ Être léger et rapide dans l’exécution des traitements (temps de réponse
acceptable).
I.2.3 Identification des acteurs

Un acteur représente un rôle joué par une entité (utilisateur humain ou dispositif
matériel) qui interagit directement avec le système étudié.

Dans ce présent système, nous avons recensé les acteurs suivants :

N NON DES ROLE

° ACTEURS

1 CONTRIBUABLE Consiste à Chercher à payer l’impôt

2 Administrateur Consiste à donne le papier de la

déclaration pour compléter les éléments
indiqués et il enregistre en donnant la note de
taxation

3 La Banque Consiste à recevoir l’argent du

paiement

Tableau 2IDENTIFICATION DES ACTEURS SYSTEME

 | 43

I.2.4 Identification de cas d’utilisations du système

Le système PASSY soft comprend les fonctionnalités suivantes :

1. Cas d’utilisation « passer demande de déclaration de paiement d’impôt » : : Il permet au

contribuable de demander la déclaration pour le paiement de l’impôt.
2. Cas d’utilisation « Taxer demande de déclaration » : Il permet à la cellule de taxation de
taxer la déclaration faite par le contribuable.
3. Cas d’utilisation « Payer déclaration impôt » : Il permet au contribuable de payer l’impôt à
la banque.
4. Cas d’utilisation « Enregistrer bordereau de paiement » : Il permet à la banque
d’enregistrer le bordereau du contribuable pour pouvoir l’envoyer au bureau de
recouvrement.
5. Cas d’utilisation « Editer quittance » : Il permet au bureau de recouvrement d’éditer la
quittance.
6. Cas d’utilisation « Authentification » : Il permet au bureau de recouvrement d’éditer la
quittance.
7. Cas d’utilisation « Gérer profil utilisateur » : Il permet à l’administrateur de rechercher,
créer, modifier ou supprimer le profil de l’utilisateur.
 | 44

I.3 Diagramme de cas d’utilisation système

Figure 6: DIAGRAMME DE CAS D'UTILISATION SYSTEME

 | 45

I.3.1 Spécification détaillée des cas d’utilisation

I.3.1.1 Classement de cas d’utilisation en itération

N° Cas d’utilisation Priorité Risque Itération

1 Passer demande de déclaration Haute Haut 2

2 Taxer demande de déclaration Haute Moyen 3

3 Payer déclaration Haute Moyen 4

4 Enregistrer bordereau de paiement Moyenne Haut 5

5 Editer quittance Moyenne Moyen 6

6 Authentification Haute Haut 1

7 Gérer profil Utilisateur Base Bas 7

Tableau 3 CLASSEMENT DES CAS D'UTILISATION EN ITERATION

Après avoir identifié les cas d’utilisation, nous pouvons maintenant les classifier en
tenant compte des deux facteurs suivants :

• La priorité fonctionnelle,
 | 46

• Le risque technique.

En suite à partir du classement de ces deux facteurs (priorité et risque), nous allons
proposer le découpage en itération ci-après :

I.4 Diagramme de séquence système

Un diagramme de séquence est un diagramme d'interaction qui expose en détail la

façon dont les opérations sont effectuées : quels messages sont envoyés et quand ils le sont.

Les diagrammes de séquences sont organisés en fonction du temps qui s'écoule au

fur et à mesure que nous parcourons la page.

Les objets impliqués dans l'opération sont répertoriés de gauche à droite en fonction
du moment où ils prennent part dans la séquence.

Nous allons décrire de façon détaillée Quelques cas d’utilisation que nous avons
identifié dans les points précédents, puis produire le diagramme de séquence :

 Objectif : Demander accès à un certain nombre de fonctionnalités du système,

 Acteur principal : Administrateur,
 Acteur secondaire : aucun,
 Précondition : Avoir un compte utilisateur actif,
 Scénario nominal :
o L’utilisateur demande la connexion.
o Le système demande à l’utilisateur de s’identifier.
o L’utilisateur fournit ses identités (Nom et mot de passe).
o Le système authentifie l’utilisateur.
o Le système autorise la connexion à l’utilisateur.

Scénario alternatif

Le système ne connecte pas l’utilisateur si les identités ne sont pas valides

et le scénario reprend en 3 du scénario ou enchainement nominal.

Post condition
 | 47

o La connexion est établie

Echec de la connexion

I.4.1 S’authentifier :

Figure 7: DIAGRAMME DE SEQUENCE AUTHENTIFICATION

 | 48

Acteur(s) : Le contribuable (principal), cellule de taxation (secondaire)

Description des scénarios

Préconditions
o Le contribuable doit être connecté au système

Scénario nominal
o Le contribuable demande la page de demande de déclaration
o Le système affiche le formulaire de demande de déclaration
o Le contribuable remplit le formulaire de demande de déclaration
o Le contribuable valide la demande de déclaration
o Le système enregistre la demande de déclaration
o Le système envoie la demande de déclaration à la cellule de taxation et à la cellule
de taxation.

Scenario alternatif

Post condition

La demande de déclaration a été enregistrée et envoyée à la cellule de taxation et

d’apurement.
 | 49

I.4.2 Passer demande de déclaration de paiement d’impôt

Figure 8: DIAGRAMME DE SEQUENCE PASSER DEMANDE DECLARATION

 | 50

 Acteur(s) : la cellule de taxation (principal)

 Description des scénarios
 Préconditions
o La demande de déclaration doit être disponible dans le système
o La cellule de déclaration doit être connectée au système.

Scénario nominal
o La cellule de taxation demande l’authentification
o Le système fait appel au cas d’utilisation « authentification »
o Le système affiche le formulaire de taxation
o La cellule de taxation remplit le formulaire de taxation
o La cellule de taxation valide la taxation de la déclaration
o Le système enregistre la taxation
o Le système retourne la déclaration au contribuable

Post condition
o La demande de déclaration a été taxée
 | 51

I.4.3 Taxer demande de déclaration

Figure 9: DIAGRAMME DE SEQUENCE TAXER DECLARATION

 | 52

 Acteur(s) : le contribuable (principal), banque (secondaire)

 Description des scénarios
 Préconditions
o La demande de déclaration a déjà été taxée
o Le contribuable doit être connecté au système

Scenario nominal
o Le contribuable demande la page d’authentification
o Le système fait appel au cas d’utilisation « authentification »
o Le système affiche le formulaire de paiement de la déclaration
o Le contribuable saisi les coordonnées de paiement
o Le système vérifie les coordonnées de paiement
o Le système établit le bordereau
o Le système envoie à la direction générale la preuve de paiement
 Scénario alternatif
Les coordonnées de paiement ne sont pas valides

Le système rejette le paiement de la déclaration

 Post condition
La demande de déclaration a été réglé et le bordereau a été enregistré et envoyé à la
direction générale.
 | 53

I.4.4 Payer déclaration impôt

Figure 10: DIAGRAMME DE SEQUENCE PAYER DECLARATION IMPOT

 | 54

 Description des scénarios

Préconditions
o S’authentifié

Scénario nominal

o Le bureau du recouvrement s’authentifié

o Le bureau du recouvrement cherche le bordereau de déclaration faite par le
contribuable
o Le système fait appel au cas d’utilisation « payer déclaration impôt »
o Le bureau du recouvrement sélectionne le bordereau du contribuable
o Le système envoie le bordereau de déclaration au bureau de recouvrement

Post condition

Le bordereau de déclaration et envoyée au bureau de recouvrement pour l’édition de la

quittance.
 | 55

I.4.5 Enregistrer bordereau de paiement

Figure 11: DIAGRAMME ENREGISTRER BORDEREAU DE PAIEMENT

 | 56

Description des scénarios

 Préconditions
o Le bureau de recouvrement doit être authentifié au système
o Le bordereau de paiement de la déclaration a été envoyé par la banque
 Scénario nominal
o Le bureau de recouvrement s’authentifie
o Le système affiche le formulaire d’édition de la quittance
o Le bureau de recouvrement remplit le formulaire d’édition de la quittance
o Le bureau de recouvrement valide le formulaire d’édition de la quittance.
I.4.6 Editer quittance

Figure 12 : Diagramme séquence éditer quittance

 | 57

Acteur(s) : l’administrateur (principal)

Description des scénarios

 Préconditions
o L’administrateur doit être connecté
o L’utilisateur existe déjà dans la base de données
 Scénario nominal
o L’administrateur cherche l’utilisateur
o Le système affiche les identités de l’utilisateur
 Scénario (a) : suppression du profil utilisateur
o L’administrateur demande la suppression de l’utilisateur
o Le système affiche le message « êtes – vous sur de vouloir supprimer cet
utilisateur ? »
o L’administrateur valide la suppression
o Le système supprime l’utilisateur
 Scénario(b) : modification du profil utilisateur
o L’administrateur demande la page de modification de l’utilisateur
o Le système affiche la page de modification de l’utilisateur
o L’administrateur saisit les anciennes et les nouvelles identités de l’utilisateur
o L’administrateur valide la modification
o Le système enregistre la modification du profil utilisateur
 Scénario alternatif
o Créer utilisateur
o L’administrateur saisit les identités du nouvel utilisateur
o L’administrateur valide l’enregistrement
o Le système crée le profil utilisateur.
 Post condition
o L’utilisateur est géré

L’utilisateur a été créé avec succès

 | 58

I.4.7 Gérer profil utilisateur

| 59
 | 60

Figure 13:Diagramme gérer profil utilisateur

I.5 Diagrammes de classes participantes

Le diagramme de classes participantes modélise l’ensemble des classes d’analyse qui

concourent à la réalisation de chaque cas d’utilisation. Dans ce diagramme, Dl signifie
Dialogue, Ctrl signifie Contrôleur et Enta signifie Entité :

I.5.1  Authentification
 

Figure 14:Diagramme de classe participante Authentification

 | 61

I.5.2 Passer demande de déclaration de paiement de l’impôt

Figure 15:Diagramme de classe participante passer demande déclaration

 | 62

I.5.3 Taxer demande de déclaration

Figure 16: Diagramme de classe participante taxer déclaration

I.5.4 Payer la déclaration de l’impôt

Figure 17: Diagramme de classe participante payer déclaration impôt

 | 63

I.5.5 Enregistrer bordereau de paiement 

Figure 18:Diagramme de classe participante enregistrer bordereau de paiement

  

I.5.6 Editer quittance

Figure 19: Diagramme de classe participante éditer quittance

 
 | 64

I.5.7 Gérer profil utilisateur 

Figure 20:Diagramme de classe participante gérer profil utilisateur

I.6 DIAGRAMME D’INTERACTION

 | 65

I.6.1 Authentification 

Figure 21:Diagramme d'interaction Authentification

 | 66

I.6.2 Passer demande de déclaration de paiement de l’impôt

Figure 22:Diagramme d'interaction passer demande déclaration

 | 67

I.6.3 Taxer demande de déclaration

Figure 23:Diagramme d'interaction taxer déclaration

 | 68

I.6.4 Payer la déclaration de l’impôt

Figure 24:Diagramme d'interaction payer déclaration impôt

 | 69

I.6.5 Enregistrer bordereau de paiement   

Figure 25:Diagramme d'interaction enregistrer bordereau paiement

 | 70

I.6.6 Editer quittance

Figure 26:Diagramme d'interaction éditer quittance

I.6.7 Gérer profil utilisateur   

| 71
 | 72

Figure 27:Diagramme d'interaction gérer profil utilisateur

I.7 Diagramme de classe conception globale

 | 73

I.8 Model logique de données

Dans le point précédent, nous avons produit les classes entités, ces classes sont la
représentation conceptuelle de données qui doivent être manipulées dans le système. En
effet ces données doivent être stockées et permanant afin d’être manipulées.

C’est ainsi qu’à ce niveau, nous devons traduire les classes entité en modèle
logique de donnée (MLD), qui est la représentation finale des données. Le modèle logique
de données nous permettra en outre de décrire la structure des données utilisée sans faire
référence au langage de programmation.

Cependant pour transformer le modèle de domaine en MLD nous devons respecter

les règles de traduction qui suivent :

 Relation un-a-un :
- Fusionner les deux classes si elles s’obtiennent à la réalisation d’un seul cas
d’utilisation. Le nom de la relation au niveau logique peut être la fusion des noms de
deux classes ou on choisit un nom
- Si les deux classes ne sont pas obtenues dans un seul cas d’utilisation la clé primaire
de la classe obtenue en première migre dans la relation issue de la classe obtenue en
dernière, ainsi ajoutée, elle joue le rôle de la clé étranger
 Relation un-a-plusieurs
Dans cette relation l’identifiant de classe père migre dans la relation
issue de la classe fils, l’attribut ainsi ajoute, et il joue le rôle de la clé étrangère.
 Relation plusieurs-a-plusieurs
La classe association devient une table en MLD (model logique de données)
dont la clé primaire est composée par la concaténation des identifiants des classes
connectes à l’association.
Lorsqu’il y a la présence d’une généralisation il existe trois méthodes

Méthode 1 : Créer une table avec tous les attributs des classes. Ajouter un attribut
pour distinguer les types de tables.

Méthode 2 : Créer une table pour chaque sous type, chaque table se compose des
attributs génériques et d’attributs spécifiques.
 | 74

Méthode 3 : Créer une table par classe et des associations.

I.8.1 Présentation du modèle logique de données

Figure 28 :MLD
 I.8.2 Model physique de données

Création des tables

 User
 | 77

 Compte

 Fiche_declaration
| 78
 | 79

 Note taxation

 Quittance
 | 80

Figure 29Modèle physique des données

I.9 Diagramme de déploiement

Le diagramme de déploiement spécifie la configuration physique des différents

matériels qui participent à l’exécution du système, la manière dont les composants du système
sont répartis ainsi que les relations entre eux. Les éléments utilisés par un diagramme de
déploiement sont principalement les nœuds, les composants, les associations et artefacts.

Les principaux nœuds de notre diagramme de déploiement sont :

 Le Client : c’est le navigateur, il permet à un utilisateur d’accéder au serveur.

En d’autres termes, il sert d’interface à l’utilisateur.
 Le serveur : C’est le serveur principal qui abrite les différents composants de
notre site web. Ces composants sont entre autres :
 | 81

• L’Application Web : l’application proprement dit qui est déployé sur le

serveur web.
• Le Serveur Web : assure la gestion des connexions et des requêtes du
client. Il assure aussi la distribution des pages JS et HTML.
• La Base de données : c’est le composant qui s’occupe du stockage et de
gestion des données.
 | 82

Figure 30 Diagramme de déploiement

 Page | 83

CHAPITRE II:  DEVELOPPEMENT DE L’ARCHITECTURE

PASSY soft
II.1 Architecture logiciel
II.2 Environnement de développement
II.2.1 Matériels
II.3 Choix de la technologie
II.3.1 Langage de programmation
II.3.2 Logiciel de développement

II.4 Description des maquettes

II.4.1 Description maquette
II.5 Quelques captures des codes
 Page | 84

CONCLUSION GENERALE

« Nous voici arrivés au terme de notre étude intitulé » Analyse et conception

par la méthode UP d’une architecture client/serveur de déclaration et paiement des
impôts ».

Quelle solution pourrions-nous apporter Afin de remédier aux différents

problèmes que rencontre les utilisateurs dans le processus de déclaration et paiement
des impôts ? Etant la problématique de notre travail ; pour parvenir à cela : nous
nous sommes principalement intéressés à connaitre les difficultés rencontrées au
sein de la DRHKAT dans le processus de déclaration et de paiement des impôts.

A partir de l’hypothèse selon laquelle une application et une base des données
serait une solution adéquate aux difficultés rencontrées dans cet établissement de
l’Etat. Pour arriver à atteindre cet objectif nous avions opté d’utiliser la méthode UP
qui est un processus de développement logiciel qui est itératif et incrémentale,
centré sur l’architecture, piloté par le cas d’utilisation et conduit par la diminution
des risques et en utilisant le langage de modélisation UML, au cours de ce mémoire,
nous avons présenté les différentes étapes de la conception avec le langage de la
modélisation UML.

Afin de satisfaire les besoins des utilisateurs nous avons commencé la

conception en utilisant les formalisations UML et la mise en œuvre d’une base de
données avec le gestionnaire de bases de données MYSQL, en suite
l’implémentation des requêtes SOL pour manipuler des données.

Ce projet a fait l’objet d’une expérience intéressante, qui nous a permis

d’améliorer nos connaissances et nos compétences dans le domaine de la
conception, nous avons appris à mieux créer les tables en utilisant les différentes
requêtes et à la manipulation de ces requêtes SQL et l’utilisation des différents
diagrammes UML.
 Page | 85

En effet, ce travail étant une œuvre humaine, n’est pas un modèle unique et
parfait, c’est pourquoi nous restons ouverts à tout critiques et nous sommes prêts à
recevoir toutes les suggestions et remarques qui nous permettraient d’améliorer
notre étude dans les jours à venir.
 Page | 86

chapitre III: TABLE DES MATIÈRES

epigraphe................................................................................................................I

liste des figures....................................................................................................IV

chapitre I: Liste des tableaux.............................................................................V

liste des abreviation.............................................................................................VI

INTRODUCTION GENERALE...........................................................................7

CHAPITRE I: ETAT DE L’ART SUR l’ARCHITECTURES

CLINT/SERVEUR ET PRESENTATION DE LA METHODE UP..............................12

I.3 CONCEPTION DES ARCHITECTURES LOGICIELS......................12

I.4 ENVIRONNEMENT CLIENT SERVEUR..........................................13

I.4.1 Serveur..............................................................................................13

I.4.2 CLIENT............................................................................................13

I.4.3 LES ARCHITECTURES.................................................................14

I.5 NIVEAU D’ABSTRATION D’UNE APPLICATION.........................15

I.5.1 ARCHITECTURE un-tiers...............................................................15

I.5.2 ARCHITECTURE à 2-tiers..............................................................16

I.5.3 ARCHITECTURE à 3-tiers..............................................................17

I.5.4 Comparaison des deux types d’architecture.....................................18

I.5.5 ARCHITECTURE à N-tiers.............................................................18

I.6 Caractéristique des systèmes client/serveur...........................................19

I.7 TYPE DES CLIENTS...........................................................................19

 Page | 87

I.7.1 Client léger.......................................................................................19

I.7.2 Client lourd.......................................................................................20

I.7.3 Client riche.......................................................................................20

I.8 LA REPARTITION DES TACHES......................................................21

I.9 LES DIFFERENTS MODELES DE CLIENT/SERVEUR...................21

I.9.1 LE CLIENT-SERVEUR DE PRESENTATION.............................21

I.9.2 LE CLIENT-SERVEUR TRAITEMENT........................................21

I.9.3 LE CLIENT-SERVEUR DES DONNEES......................................22

I.10 AVANTAGES ET INCOVENIENTS...............................................22

I.10.1 AVANTAGES................................................................................22

I.10.2 INCOVENIENTS...........................................................................22

SECTION 2 PRESENTATION DE LA METHODE UP...................................23

I.11 UNIFIED MODELING LANGAGE (UML)....................................24

I.11.1 Définition de l’UML.......................................................................24

I.11.2 Point fort d’UML............................................................................25

I.11.3 Point faibles d’UML.......................................................................25

I.12 PROCESSUS UNIFIE(UP)...............................................................25

I.12.1 Définition du processus unifie........................................................25

I.12.2 Les caractéristiques du processus unifie.........................................26

CHAPITRE II: ANALYSE METRIER SUR LE PAIEMENT DES IMPOTS AU

SEIN DE LA DRHKAT..................................................................................................29

SECTION 2 MODELISATION METIER..........................................................32

 Page | 88

chapitre II: conception du nouveau système d’information PASSY soft.........39

I.1 Conception logique....................................................................................39

I.2 Spécifications des besoins..........................................................................39

I.2.1 Les besoins fonctionnels.....................................................................39

I.2.2 Les besoins non fonctionnels..............................................................39

I.2.3 Identification des acteurs.....................................................................40

I.2.4 Identification de cas d’utilisations du système....................................41

I.3 Diagramme de cas d’utilisation système....................................................42

I.3.1 Spécification détaillée des cas d’utilisation........................................43

I.3.1.1 Classement de cas d’utilisation en itération.................................43

I.4 Diagramme de séquence système...............................................................44

I.4.1 S’authentifier :.....................................................................................46

I.4.2 Passer demande de déclaration de paiement d’impôt..........................48

I.4.3 Taxer demande de déclaration.............................................................50

I.4.4 Payer déclaration impôt.......................................................................52

I.4.5 Enregistrer bordereau de paiement......................................................54

I.4.6 Editer quittance...................................................................................56

I.4.7 Gérer profil utilisateur.........................................................................58

I.5 Diagrammes de classes participantes.........................................................60

I.5.1 Authentification...................................................................................60

I.5.2 Passer demande de déclaration de paiement de l’impôt......................60

I.5.3 Taxer demande de déclaration.............................................................61

 Page | 89

I.5.4 Payer la déclaration de l’impôt............................................................61

I.5.5 Enregistrer bordereau de paiement......................................................61

I.5.6 Editer quittance...................................................................................62

I.5.7 Gérer profil utilisateur.........................................................................62

I.6 DIAGRAMME D’INTERACTION...........................................................63

I.6.1 Authentification...................................................................................63

I.6.2 Passer demande de déclaration de paiement de l’impôt......................64

I.6.3 Taxer demande de déclaration.............................................................65

I.6.4 Payer la déclaration de l’impôt............................................................66

I.6.5 Enregistrer bordereau de paiement......................................................67

I.6.6 Editer quittance...................................................................................68

I.6.7 Gérer profil utilisateur.........................................................................69

I.7 Diagramme de classe cnception.................................................................71

I.8 Model logique de données..........................................................................71

I.8.1 Présentation du modèle logique de données.......................................72

I.8.2 Model physique de données................................................................74

I.9 Diagramme de déploiement.......................................................................78

CHAPITRE II: REALISATION DE L’ARCHITECTURE PASSY soft..........81

II.1 Architecture logiciel..................................................................................81

II.2 Environnement de développement............................................................81

II.2.1 Matériels............................................................................................81

II.3 Choix de la technologie............................................................................81

 Page | 90

II.3.1 Langage de programmation...............................................................81

II.3.2 Logiciel de développement................................................................81

II.4 Description des maquettes........................................................................81

II.4.1 Description maquette.........................................................................81

II.5 Quelques captures des codes.....................................................................81

CONCLUSION GENERALE.................................................................81

chapitre III: Table des matières.........................................................................82