Redaction

RÉPUBLIQUE DE COTE D’IVOIRE
UNION – DISCIPLINE – TRAVAIL

Ministère de l’enseignement supérieur et de la recherche scientifique
RAPPORT DE PROJET INTERNE
THÈME :
CONCEPTION ET MISE EN ŒUVRE D’UNE
APPLICATION WEB POUR LA GESTION DE
LA MUTUELLE DU PERSONNEL DE L’INP-HB
(MU.P.I)
ENCADREUR PRÈSENTE PAR
ADOU Kouamé Jean Jacques
M. KOFFI Arsène AMANI Leslie Jean De Capistran
GNONGUI Aguichi Géoffroy Jacques
Enseignant-chercheur à l’INP-HB
ILLIASSOU Zougaou Ibrahim
TS Informatique 3 2017 – 2018

DÉDICACE
Nous dédions ce mémoire :
• à nos familles respectives, qui n’ont ménagé aucun effort pour nous soutenir
durant toutes nos années d’étude ;
• à nos ami(e)s et camarades à qui nous témoignons une grande reconnaissance.
I
REMERCIEMENTS
Nous n’avons pas la présomption d’affirmer que nous sommes arrivés à
l’élaboration de ce mémoire seulement grâce à nos capacités. C’est pour cette raison
que nous tenons à exprimer notre sincère et profonde reconnaissance à tous ceux et
à toutes celles qui ont contribué par leurs conseils, leurs soutiens et leurs critiques
constructives à la réalisation de ce mémoire.
En effet, le rapport suivant a été réalisé grâce au soutien constant et à

l'assistance sans réserve de personnes de bonne volonté. Ainsi nos remerciements
vont à l'endroit de M. KOFFI Arsène, notre encadreur pédagogique, pour sa
disponibilité qu’il nous a accordé tout au long de ce projet.
Nous adressons également nos remerciements à toute l'équipe pédagogique de

l'Ecole Supérieure d’Industrie (ESI) et particulièrement ceux du DFR-MI pour les
connaissances transmises au cours de nos années de formation.
De même nous tenons vivement à remercier les membres du jury pour

l’honneur qui nous est fait en acceptant de juger notre travail.
II
SOMMAIRE
DÉDICACE ......................................................................................................................................... I
REMERCIEMENTS ................................................................................................................................. II
SOMMAIRE ........................................................................................................................................ III
LISTE DES FIGURES .............................................................................................................................. IV
LISTE DES TABLEAUX ............................................................................................................................ V
AVANT-PROPOS.................................................................................................................................. VI
INTRODUCTION ................................................................................................................................... 1
PARTIE 1 : ÉTUDE PREALABLE .................................................................................................................. 2
CHAPITRE I : PRÉSENTATION DE LA STRUCTURE D’ACCUEIL................................................................................ 3
I. PRÉSENTATION ........................................................................................................................ 3
II. OBJET DE LA MU.P.I .................................................................................................................. 3
III. ORGANIGRAMME DE LA Mu.P.I ................................................................................................... 3
CHAPITRE II : PRÉSENTATION DU PROJET..................................................................................................... 5
I. PRÉSENTATION DU THÈME ........................................................................................................... 5
II. PRÉSENTATION DU CAHIER DES CHARGES.......................................................................................... 5
III. ÉTUDE DE L’EXISTANT ............................................................................................................ 8
PARTIE 2 : ÉTUDE CONCEPTULLE .............................................................................................................. 9
CHAPITRE III : MÉTHODE D’ANALYSE ET DE CONCEPTION ................................................................................ 10
I. PRÉSENTATION DU PU/UML........................................................................................................ 11
II. PRÉSENTATION DE MERISE ......................................................................................................... 18
III. CHOIX DE LA MÉTHODE ......................................................................................................... 20
CHAPITRE IV : CONCEPTION DU SYSTÈME ................................................................................................... 25
I. DÉFINITION ET ANALYSE DES BESOINS ............................................................................................ 25
II. DEVELOPPEMENT DU MODELE STATIQUE : DIAGRAMME DE CLASSE ........................................................... 64
PARTIE 3 : ÉTUDE TECHNIQUE ET RÉALISATION ............................................................................................ 69
CHAPITRE V : CHOIX DES TECHNIQUES DE MISE EN OEUVRE ............................................................................. 70
I. ARCHITECTURE DE LA SOLUTION.................................................................................................. 70
II. ÉTUDE ET CHOIX DU SYSTÈME DE GESTION DE BASE DE DONNÉES (SGBD) ................................................... 79
III. ÉTUDE ET CHOIX DE LA TECHNIQUE DE DEVELOPPMENT ................................................................... 80
IV. SERVEUR D’APPLICATION ....................................................................................................... 82
V. PRÉSENTATION ET CHOIX DES FRAMEWORK ..................................................................................... 85
VI. OUTILS DE DEVELOPPEMENT ................................................................................................... 87
CHAPITRE VI : RÉALISATION TECHNIQUE .................................................................................................... 90
II. PRÉSENTATION DE LA SOLUTION .................................................................................................. 92
CHAPITRE VII : ÉVALUATION FINACIÈRE ..................................................................................................... 94
I. ÉVALUATION JOUR-HOMME ........................................................................................................ 94
II. ÉVALUATION DE LA CHARGE RÉELLE ............................................................................................. 94
III. ÉVALUATION DES MATERIELS ET LOGICIEL ................................................................................... 95
IV. CONSTRUCTION DU PLANNING D’EXÉCUTION ................................................................................ 96
CONCLUSION .................................................................................................................................... 97
BIBLIOGRAPHIE ................................................................................................................................. VII
WEBOGRAPHIE................................................................................................................................. VIII
TABLE DES MATIÈRES ........................................................................................................................... IX
III
LISTE DES FIGURES
Figure 1 : Organigramme de la MUPI ..................................................................4
Figure 2 : Modèle représentant les 4+1 vues de Kruchten ....................................... 13
Figure 3 : La démarche du Processus Unifié ....................................................... 16
Figure 4 : Cycle de vie de PU ........................................................................ 16
Figure 5 : Deux dimensions du RUP ................................................................. 23
Figure 6 : Diagramme de contexte statique ....................................................... 26
Figure 7 : Diagramme des cas d'utilisation ......................................................... 30
Figure 8 : Diagramme de séquences du cas d'utilisation "attribuer droit" ..................... 33
Figure 9: Diagramme de séquences du cas d'utilisation "Authentification" ................... 34
Figure 10 : Diagramme de séquences du cas d’utilisation "consulter message" .............. 35
Figure 11 : Diagramme de séquences du cas d'utilisation "consulter compétences" ......... 36
Figure 12 : Diagramme de séquences du cas d'utilisation "consulter opération" ............. 37
Figure 13 : Diagramme de séquences du cas d'utilisation "créer compte" ..................... 39
Figure 14 : Diagramme de séquences du cas d'utilisation "enregistrer action" ............... 41
Figure 15 : Diagramme de séquences du cas d'utilisation "enregistrer compétences" ....... 43
Figure 16 : Diagramme de séquences du cas d'utilisation "enregistrer opération" ........... 45
Figure 17 : Diagramme de séquences du cas d'utilisation "enregistrer transaction" ......... 47
Figure 18 : Diagramme de séquences du cas d'utilisation "modifier action" .................. 49
Figure 19 : Diagramme de séquences du cas d'utilisation "modifier compétences" .......... 51
Figure 20 : Diagramme de séquences du cas d'utilisation "modifier transaction" ............ 53
Figure 21 : Diagramme de séquences du cas d'utilisation "publier message " ................. 55
Figure 22 : Diagramme de séquences du cas d'utilisation "suivi du fonctionnement" ........ 57
Figure 23 : Diagramme de séquences du cas d'utilisation "supprimer action" ................ 59
Figure 24 : Diagramme de séquences du cas d'utilisation "supprimer transaction" .......... 61
Figure 25 : Diagramme de séquences du cas d'utilisation "supprimer utilisateur"............ 63
Figure 26 : Paquetage Utilisateur du diagramme de classe ..................................... 65
Figure 27 : Paquetage Membre du diagramme de classe ........................................ 66
Figure 28 : Paquetage Opération du diagramme de classe ...................................... 67
Figure 29 : Paquetage Suivi du diagramme de classe ............................................ 68
Figure 30 : Les trois niveaux d'architecture d'une application informatique ................. 71
Figure 31 : Architecture d’une application sur site central ..................................... 72
Figure 32 : Dialogue client-serveur ................................................................. 73
Figure 33 : Accès aux données en mode client serveur .......................................... 73
Figure 34 : Positionnement du middleware entre client et serveur ............................ 74
Figure 35 : Architecture 3-tiers...................................................................... 75
Figure 36 : Schéma du modèle MVC ................................................................. 78
Figure 37 : Architecture conteneur web java ..................................................... 84
Figure 38 : Diagramme de déploiement ............................................................ 91
Figure 39 : Interface d’accueil de l’application ................................................... 92
Figure 40 : Interface de connexion.................................................................. 93
IV
LISTE DES TABLEAUX
Tableau 1 : Comparaison MERISE-UML .............................................................. 20
Tableau 2 : Liste des messages entre le système et les acteurs externes..................... 28
Tableau 3 : Les cas d'utilisation ..................................................................... 29
Tableau 4 : Description textuelle de cas d’utilisation "Attribuer droit" ....................... 32
Tableau 5 : Description textuelle du cas d’utilisation "authentification" ..................... 34
Tableau 6 : Description textuelle du cas d’utilisation "consulter message" ................... 35
Tableau 7 : Description textuelle du cas d’utilisation "consulter compétences" ............. 36
Tableau 8 : Description textuelle du cas d’utilisation "consulter opération" ................. 37
Tableau 9 : Description textuelle du cas d’utilisation "créer compte"......................... 38
Tableau 10 : Description textuelle du cas d’utilisation "enregistrer action" .................. 40
Tableau 11 : Description textuelle du cas d’utilisation "enregistrer compétences" ......... 42
Tableau 12 : Description textuelle du cas d’utilisation "enregistrer opération" .............. 44
Tableau 13 : Description textuelle du cas d’utilisation "enregistrer transaction" ............ 46
Tableau 14 : Description textuelle du cas d’utilisation "modifier action" ..................... 48
Tableau 15 : Description textuelle du cas d’utilisation "modifier compétences" ............ 50
Tableau 16 : Description textuelle du cas d’utilisation "modifier transaction" ............... 52
Tableau 17 : Description textuelle du cas d’utilisation "publier message" .................... 54
Tableau 18 : Description textuelle du cas d’utilisation "suivi du fonctionnement" .......... 56
Tableau 19 : Description textuelle du cas d’utilisation "supprimer action" ................... 58
Tableau 20 : Description textuelle du cas d’utilisation "supprimer transaction" ............. 60
Tableau 21 : Description textuelle du cas d’utilisation "supprimer utilisateur" .............. 62
Tableau 22 : Résumé comparatif des architectures .............................................. 77
Tableau 23 : Résumé comparatif des SGBD ........................................................ 80
Tableau 24 : Résumé comparatif des technologies de développement ........................ 82
Tableau 25 : Résumé comparatif des serveurs d'application .................................... 84
Tableau 26 : Résumé comparatif des IDE .......................................................... 89
Tableau 27 : Cours de la charge JOUR-HOMME .................................................... 95
Tableau 28 : Récapitulatif des cours matériel et logiciels du projet .......................... 95
Tableau 29 : Plan d'exécution ....................................................................... 96
V
AVANT-PROPOS
Basé à Yamoussoukro et situé à huit (8) kilomètres (km) du centre-ville,
l’Institut National Polytechnique Félix Houphouët Boigny (INP-HB) est un institut
public d’Enseignement Supérieur et de Recherches, ayant pour vocation la formation
de Techniciens Supérieurs et d’Ingénieurs dans différents domaines, aptes à servir
les entreprises. L’INP-HB a été créé par le décret numéro 96-678 du 04 septembre
1996, portant sur la restructuration et la fusion des quatre ex-grandes écoles à
savoir :
− L’Ecole Nationale Supérieure d’Agronomie (ENSA) ;
− L’Ecole Nationale Supérieure des Tavaux Publics (ENSTP);
− L’Institut Agricole de Bouaké (IAB);
− L’Institut National Supérieur de l’Enseignement Technique (INSET).
L’INPHB regroupe six (6) grandes écoles en plus d’une école doctorale et la Data
Science Institute reparties sur trois sites que sont :
• L’INPHB Nord
o L’Ecole Supérieure d’Agronomie (ESA) ;
o L’Ecole de Formation Continue et de Perfectionnement des Cadres
(EFCPC) ;
o L’Ecole Doctorale Polytechnique (EDP).
• L’INPHB Centre
o L’Ecole Supérieure de Commerce et d’Administration des Entreprises
(ESCAE) ;
o L’Ecole Supérieure d’Industrie (ESI) ;
o L’Institut de Data Science.
• L’INPHB Sud
o L’Ecole Supérieure des Mines et de Géologie (ESMG) ;
o L’Ecole Supérieure des Travaux publics (ESTP) ;
o Classes préparatoires aux grandes écoles (CPGE).
Les missions assignées à l’INPHB sont diverses et variées à savoir :
− La formation initiale et la formation continue : formations qualifiantes
(recyclage, perfectionnement) des techniciens supérieurs, des ingénieurs des
techniques et des ingénieurs de conception dans les domaines de l'industrie,
du commerce, de l'administration, du génie civil, des mines et de la géologie;
− La recherche et les développements appliqués dans les domaines cités
précédemment.
Partageant la vocation générale de l’Institut, la direction de l’ESI organise pour les
étudiants en fin de cycle, une vague de soutenances qui portent sur différents
thèmes ou sujets de projet – appelé projet interne – attribués à chaque étudiant en
vue de les amener à réaliser une première application à partir de leurs connaissances
générales acquises durant leurs parcours académiques aux réalités d’un projet
concret.
VI
INTRODUCTION
L’Institut National Polytechnique Felix Houphouët-Boigny (INP-HB), est un
pionnier, dans la sous-région, dans la formation des cadres compétents dans tous les
secteurs d’activités pourvoyeurs de développement. A cet effet, l’INPHB dispose
pour son fonctionnement, des structures administratives, techniques et
pédagogiques, définies selon ses propres ambitions. Le type d’administration adopté
est le fruit de dizaines d’années d’expériences capitalisées par les anciens
établissements dont il est issu. Pour assurer son organisation l’Institut dispose en
outre d’une administration efficiente et de moyens techniques suffisants. On note
donc un personnel administratif et technique, conséquent et performant dans
l’exécution des taches afin d’assurer le bon fonctionnement de l’Institut.
Pour s’assurer un soutien social, renforcer la cohésion, le personnel s’est organisé,

en dehors de l’organisation administratif de l’INPHB, au sein d’une mutuelle
dénommé Mu.P.I : Mutuelle du Personnel de l’INP-HB. La Mu.P.I a un fonctionnement
propre et indépendant ; elle a une direction exécutive, des activités, des projets et
entretient des partenariats. Tout ceci dans le but de concourir au bien-être et à
l’épanouissement des mutualistes que sont les membres du personnel de l’INP-HB.
Vu l’ampleur de sa tâche, la gestion difficile et fastidieuse de ses opérations et du
nombre assez important de ses membres, la Mu.P.I désire automatiser la gestion de
toutes ses activités. D’où la pertinence du thème soumis à notre étude dans le cadre
de notre projet interne : « CONCEPTION ET MISE EN ŒUVRE D’UNE APPLICATION
WEB POUR LA GESTION DE LA MUTUELLE DU PERSONNEL DE L’INP-HB (MU.P.I) ».
Le sujet présenté ci-dessus éveille en nous nombre de questionnements utiles pour

son appréhension. En effet, comment est organisé la Mu.P.I ? Comment fonctionne-
t-elle ? Quelles connaissances théoriques et techniques faut-il mobiliser pour réussir
un projet de conception et de mise en œuvre d’une application web ? Et quelles en
sont les ressources humaines et financières nécessaires ?
La réponse à cette problématique devrait nous amener à réussir un examen abouti

suivant un plan précis et clair. La suite de notre travail est structurée donc selon
trois parties. D’abord une première partie d’étude préalable qui consistera en la
remise du sujet dans son contexte, la présentation du projet et l’étude du
fonctionnement de la gestion de la mutuelle ainsi que l’examen de ses besoins
d’informatisation. Ensuite une deuxième partie qui intervient pour une modélisation
des fonctionnalités et du métier de l’application demandée. Une modélisation qui
serait potable pour une implémentation. Enfin une troisième partie qui consistera en
l’étude des solutions technologiques et des ressources humaines et financières
nécessaires à la réalisation de l’application.
1
PARTIE 1
ÉTUDE PRÉALABLE
L’objet de cette partie est de fixer le cadre d’étude du projet afin d’en avoir une
bonne et claire compréhension. Nous allons par conséquent présenter la structure
d’accueil, le thème qui nous a été soumis ainsi que les techniques de gestion de
projet mises en place.
2
CHAPITRE I : PRÉSENTATION DE LA
STRUCTURE D’ACCUEIL
I. PRÉSENTATION
Cohésion, entente, solidarité entre les agents, sont les mots qui ont guidé l’Institut
National Polytechnique Félix HOUPHOUET-BOIGNY (INP-HB) de Yamoussoukro a créé
la Mutuelle du Personnel de l’INP-HB (MU.P.I.) régie par la loi n°60-315 du 21
septembre 1960 relative aux associations en Côte d’Ivoire.
II. OBJET DE LA MU.P.I

La mutuelle a un caractère fondamentalement social. Elle assiste ses membres dans
les événements heureux ou malheureux prévus par le Règlement Intérieur. Elle est
chargée de mener toutes les activités à caractère social proposées par le Bureau
Exécutif (B.E.) et dûment approuvées par le Comité de Surveillance et de Contrôle.
La Mutuelle est apolitique et ne relève d’aucun groupement syndical ou
confessionnel.
III. ORGANIGRAMME DE LA Mu.P.I
3
PRESIDENT
1ER VICE-PRESIDENT 2EME VICE-PRESIDENT
SECRETAIRE GENERAL
SECRETAIRE GENERAL
TRESORIERE GENERALE ADJOINT
TRESORIER GENERAL
ADJOINT
COMMISSION
COMMISSION COMMISSION
COMMISSION CHARGEE CHARGEE DE
CHARGEE DES CHARGEE DU
DES AFFAIRES SOCIALES L’INFO, DE LA
AFFAIRES SPORT ET DES
ET DE LA SANTE COMM ET DE LA
EXTERIEURES LOISIRS
MOBILISATION
Figure 1 : Organigramme de la MUPI
4
CHAPITRE II : PRÉSENTATION DU
PROJET
I. PRÉSENTATION DU THÈME
Le projet qui est soumis à notre étude est : « CONCEPTION ET MISE EN ŒUVRE
D’UNE APPLICATION WEB POUR LA GESTION DE LA MUTUELLE DU
PERSONNEL DE L’INP-HB (Mu.P.I) ». Il fait ressortir un terme fort important dont la
définition permettra une compréhension claire :
• Application web : Une application web désigne un logiciel applicatif hébergé
sur un serveur et accessible via un navigateur web au moyen d'une connexion
à Internet. Les technologies utilisées pour développer les applications web
sont les mêmes que celles employées dans la création des sites internet.
Pour mieux mener notre étude et surtout, dans l’optique de prendre en compte tous
les aspects techniques et fonctionnels qui entourent le projet, il convient d’étudier
le fonctionnement actuel de ladite mutuelle et de faire par la suite quelques
critiques en ce qui concerne son existant informatique.
II. PRÉSENTATION DU CAHIER DES

CHARGES
1- Présentation du contexte
Dans le but d’améliorer ses actions sociales qui visent le bon épanouissement de ses
mutualistes la Mu.P.I décide de passer à une informatisation de son organisation, de
son fonctionnement dont nous donnons ici une description :
✓ Les membres de la Mu.P.I sont les fonctionnaires de l’Etat en fonction à l’INP-
HB. Un membre de la Mu.P.I peut se retirer de la mutuelle : le concerné doit
remplir une lettre et la déposée auprès du président de la mutuelle. Chaque
mois, un prélèvement est effectué sur le compte des membres ; soit 2000
FCFA pour le personnel administratif et technique et 3000 FCFA pour les
enseignants.
La Mu.P.I est en partenariat avec d’autres structures externes telles que les
pharmacies, les boutiques électro-ménagères, etc. Les membres peuvent
effectuer des opérations dans ces structures partenaires. Mais, toutes les
dépenses effectuées seront comptabilisées pour effectuer un prélèvement
mensuel concernant chaque membre.
5
Aussi, une vérification est effectuée avec un exemplaire du reçu que les
structures partenaires apportent à ladite mutuelle. (Les membres devraient
eux aussi apporter les reçus de chaque opération). Ladite mutuelle sauvegarde
seulement la somme des dépenses effectuées par membre. Pour offrir des
opportunités à ses membres, ladite mutuelle veut mettre en place une base
de données des compétences de ses membres afin que des personnes
extérieures puissent consulter les différents profils.
✓ Chaque année, la mutuelle peut effectuer une ou plusieurs activités dont
l’organisation nécessite éventuellement une participation individuelle de ses
membres. Un membre peut participer à une ou plusieurs activités. De plus,
des cotisations exceptionnelles peuvent être effectuées pour les activités
organisées.
Quelques activités :
• les récurrents
o Tous les décembres : organisation d’un diner (arbre de noël et
tombola). Des tickets pour la tombola et pour l’entrée au diner
gala sont vendu au près des membres.
o Deux sorties détentes prévues chaque année. Chaque membre
désirant participer devra s’acquitter des frais.
o Journée du mutualiste en Mai pendant la fête du travail :
récompense du meilleur agent hommage aux retraités.
o AG ordinaire chaque année : bilan morale et bilan financier.
o Tournoi sportif inter-service.
• les projets
o Mise en place de la boutique du mutualiste
o Projet d’acquisition de terrain avec Ephraïm SARL
o Annuaire du mutualiste : liste les compétences pour les membres
✓ Différentes prestations sont effectuées par la mutuelle auprès de ses
membres, qui consistent en partie à leur apporter un soutien financier et
moral selon les cas suivants :
• Décès (Membre, Père ou mère, conjoint(e), Enfant)
• Mariage
• Retraite
• Mutation
• Naissance
✓ La trésorerie procède chaque fois à l’ :
• Enregistrement des cotisations ordinaires et exceptionnelles
• Enregistrement des sorties de fonds pour activité ou prestation ou
paiement de structure partenaire.
La Mu.P.I souhaite donc disposer d’une application informatique qui facilitera sa
gestion. L’application devra être nécessairement une application web. Cette
application a pour but premier d’optimiser le fonctionnement de la Mu.P.I.
6
La solution devra prendre en compte toutes les spécificités des prestations, de la
caisse, des opérations des membres chez les partenaires de la Mu.P.I ainsi que les
différentes activités que celle-ci organise. Dans le but de satisfaire les membres de
ladite Mutuelle (Mu.P.I), la solution devra aussi être répartie en plusieurs modules,
chaque module représentant un domaine de fonctionnement de ladite mutuelle, et
présenter une interface facilement compréhensible reprenant la démarche actuelle
de gestion.
2- Objectifs principaux de l’application

Les objectifs de l’application de gestion sont multiples. L’application devra tout
d’abord être extrêmement fiable, son domaine d’application concernant le cœur du
fonctionnement de la MUPI. L’objectif principal est la gestion des membres de la
MUPI, de ses activités, de sa trésorerie, des prestations envers ses membres ainsi
que de ses différents partenariats. L’application devra notamment :
− Faire le suivi des opérations effectuées par les différents membres chez
chaque partenaire ;
− Informer les membres de la tenue d’une activité, de la délivrance d’une
prestation, de l’acquisition de nouveaux partenaires, de l’avènement de
nouveaux projets … ;
− Lister des membres ayant effectués une cotisation exceptionnelle à la
trésorerie pour une activité donnée ;
− Faire le suivi les cotisations mensuelles des membres ;
− Lister les prestations effectuées au près d’un membre ;
− Faire le suivi de chaque sortie de fonds par la trésorerie dédiée aux activités,
aux prestations, aux projets ou encore aux partenaires ;
− Faire La réalisation promotion des membres : présentation de chaque membre
et de ses compétences ;
− Publier des annonces sur les activités, les projets, les prestations (décès,
mariage, naissance, …) et tout autre évènement possible.
Les objectifs de second niveau, découlant des objectifs principaux sont :
− Permettre d’établir des statistiques relatives aux informations enregistrées ;
− Permettre l’édition des états.
Analysons à présent les besoins auxquels doit répondre l’application. Les besoins non
fonctionnels correspondent à la manipulation de l’application et précisent
l’environnement de l’application. Les besoins fonctionnels listent les opérations
réalisables avec l’application.
7
III. ÉTUDE DE L’EXISTANT
1- Étude de l’existant
La Mu.P.I Mutuelle du personnel de l’INP-HB ne dispose d’aucune ressource
informatique à savoir ordinateur personnel, poste de travail, serveur, réseau local,
imprimante … Elle dispose d’un gestionnaire informatique qui utilise son ordinateur
personnel pour effectuer les tâches qui lui sont assigné.
2- Objectifs
Les objectifs en termes d’acquisition de ressources informatiques propres à la Mu.P.I
sont motivés ici dans le contexte de réalisation d’une application web pour la gestion
de ladite mutuelle. La Mu.P.I souhaite donc pour l’utilisation de cette application
web acquérir plusieurs ordinateurs, une connexion internet et une imprimante.
8
PARTIE 2
ÉTUDE CONCEPTUELLE
Dans cette partie, il sera question d’une analyse perspicace des besoins des
utilisateurs afin d’avoir une meilleure appréhension du système à concevoir. Nous
procéderons ensuite à la présentation des différents modèles de conception qui
découlent de cette analyse.
9
CHAPITRE III : MÉTHODE D’ANALYSE
ET DE CONCEPTION
Pour concevoir un système d’information fiable, il est nécessaire de
comprendre la structure dans laquelle le système doit être mis en place. De cet état
de fait, il ressort l’utilité d’une méthode de conception nous permettant d’établir
un modèle représentatif de cette organisation. Il est à noter qu’une méthode
d’analyse et de conception est la réunion d’une démarche et d’un formalisme. Il
vise à formaliser les étapes du développement d’un système de sorte à aboutir à
l’adéquation du développement de la solution avec les besoins du client quant à la
conception du système d’information relatif au projet. La réalisation de la méthode
d’analyse et de conception se base sur l’existant c’est-à-dire les ressources
informatiques intervenant dans le fonctionnement de l’organisation. La phase
d’analyse a pour but d’aider à déterminer les résultats attendus selon plusieurs
critères relatifs à la qualité1 d’un logiciel à savoir les fonctionnalités, la
performance, la robustesse, la maintenabilité, la sécurité, l’extensibilité. La phase
de conception quant à elle, décrit de façon claire, s’appuyant sur un langage de
modélisation, le fonctionnement du système informatisé à venir, pour permettre une
réalisation aisée.
Il existe trois (3) approches méthodiques de construction de système informatique.
On a :
• Les méthodes systémiques :
o Merise
o Axial
• Les méthodes cartésiennes :
o Yourdon
o SADT
o Jackson
• Les méthodes objets :
o Object Modeling Technique (OMT)
o Modèle d’Analyse et de Conception d’Applications Orientées objet
(MACAO)
o Object Oriented Software Engineering (OOSE)
o Processus Unifié (PU)
Nous nous appesantirons sur les méthodes Merise et le Processus Unifié car ce sont
les méthodes vues en classe.
1
Laurent Audibert, UML 2.0, Institut Universitaire de Technologie de Villetaneuse – Département Informatique, Paris 13, p.
12-13.
10
I. PRÉSENTATION DU PU/UML
Le Processus Unifié PU (En anglais « Unified Process ») est un processus de
développement évolué, incrémental, pratique pour des projets informatiques de
toutes tailles. Très complet, il couvre l’ensemble des activités, depuis la conception
du projet jusqu’à la livraison de la solution. Il est aussi décrit comme « une méthode
générique de développement de logiciel en ce sens qu’il est nécessaire de l’adapter
au contexte du projet, de l’équipe, du domaine et/ou de l’organisation. 2». Il permet
de diriger les tâches de chaque individu et de l’équipe dans son ensemble. En outre
le processus unifié possède les caractéristiques suivantes :
• Le processus de développement est centré sur l’utilisateur ;
• L’architecture regroupe les différentes vues du système qui doit être
construit, prévoit la réalisation de tous les cas d’utilisation ;
• Le découpage du projet en « mini-projets » :
o Des itérations qui donnent à un incrément.
• La modélisation basée sur UML.
Le langage graphique (UML) sur lequel il est basé, permet de représenter,
communiquer les divers aspects d’un système d’information. « C’est un
métalangage3 car il fournit les éléments permettant de construire le modèle qui, lui,
sera le langage du projet4. »
Dans un projet, la plus grande difficulté réside dans la représentation d’un modèle
graphique complet, ce qui est impossible. Aussi UML, propose-t-il un système de vues
partielles dont l’assemblage cote à cote fournira une image utilisable minimisant le
risque d’erreurs graves. Ce système repose sur UML 2.0, qui utilise treize (13)
diagrammes représentant les vues distinctes pour représenter les concepts
spécifiques du système d’information.
1- Etude de l’existant
Comme souligné plutôt, UML utilise treize (13) regroupés en deux (2) grands
ensembles5.
• Les diagrammes structurels : ces diagrammes au nombre de dix (10)
représentent l’aspect statique.
o Le diagramme de classes : il décrit de manière générale la structure
statique du système en termes de classes et de relations entre les
classes.
o Le diagramme d’objets : il présente l’état du système à un instant
donné ;
2
Jérémie Guiochet ,UP NTIE , Master 1 ,2009, p. 24.
3
C’est un langage adapté à une définition formelle de langue de programmation qui et moyen symbolique (A
cherché)
4
Laurent Audibert, UML 2.0, Institut Universitaire de Technologie de Villetaneuse – Département Informatique, Paris 13, p.
5
Joseph Gabay et David Gabay,UML 2 Analyse et conception,Paris,Dunod,2008, p 73-124 passim ; Laurent
Audibert, UML 2.0, Institut Universitaire de Technologie de Villetaneuse – Département Informatique, Paris 13, p 22-23.
11
o Le diagramme de composants : il permet de représenter les
composants logiciels d’un système de même que les liens existants
entre eux.
o Le diagramme de déploiement : il permet de représenter
l’architecture physique supportant le système d’exploitation.
o Le diagramme de paquets : un paquetage étant un conteneur logique
permettant de regrouper et d’organiser les éléments dans le modèle
UML, le diagramme de paquetages sert à représenter les dépendances
entre paquetages, c'est- à-dire les dépendances entre ensembles de
définitions ;
o Le diagramme de structure composite : il permet de décrire des
collaborations d’instances (de classes, de composants…) constituant
des fonctions particulières du système à développer.
• Les diagrammes comportementaux : les diagrammes comportementaux
mettent l’accent sur la partie dynamique du système.
o Le diagramme des cas d’utilisation : il donne un aperçu des relations
entre les acteurs (utilisateurs du cas) et le système du point de vue de
l’utilisateur ;
o Le diagramme d’états transition : il représente l’évolution les objets
appartenant à une classe ;
o Le diagramme d’activité : il permet de décrire sous forme de flux ou
d’enchaînement d’activités le comportement du système ou de ses
composants ;
o Le diagramme de séquence : il montre les interactions entre objets en
indiquant la chronologie des échanges ;
o Le diagramme de communication : il est la représentation simplifiée
d’un diagramme de séquence se concentrant sur les échanges de
messages entre les objets ;
o Le diagramme global d’interaction : Il donne une vue générale des
interactions décrites dans le diagramme de séquence et des flots de
contrôle décrits dans le diagramme d’activité ;
o Le diagramme de temps : Il met en exergue les changements que subit
une donnée au cours du temps.
12
2- Les 4 + 1 vues du Processus unifié
La réalisation d’UML passe par différentes vues pouvant se superposées afin de
collaborer à la définition du système. Le choix d’une bonne architecture étant la
pierre angulaire du développement d’un logiciel, Philippe Kruchten 6 propose une
architecture, l’architecture de 4 + 1 vues de Kruchten, basée sur les cinq (5) vues
suivantes :
• La vue des cas d’utilisation : ici, on décrit les besoins fonctionnels du point
de vue de l’utilisateur. Elle répond à deux préoccupations à savoir : Qui
participe au projet ? Quoi, qu’est-ce qui est produit durant le projet ?
• La vue logique : c’est la définition du système vu de l’intérieur. La question
on cherche à savoir comment doit-être réalisé le projet afin de satisfaire aux
besoins des utilisateurs ?
• La vue d’implémentation : cette vue définie les dépendances entre les
modules.
• La vue des processus : c’est la vue temporelle et technique qui met en œuvre
les notions de tâches concurrentes, contrôle et synchronisation ;
• La vue de déploiement : cette vue décrit la position géographique et
l’architecture physique de chaque élément du système.
Vue logique Vue d’implémentation
Vue des cas d’utilisation
Vue des processus Vue de déploiement
Figure 2 : Modèle représentant les 4+1 vues de Kruchten
6
Philippe Kructen est un ingénieur de l’Ecole Centrale de Lyon et docteur en informatique de l’Ecole Nationale
Supérieure des Télécommunications (ENST) de Paris. En ligne : https://www.editions-
eyrolles.com/Auteur/8964/philippe-kruchten, consulté le 15 Janvier 2018.
13
3- La démarche du Processus unifié
Le processus unifié possède quatre phases dont :
• La création (lancement ou pré-étude)7 : elle permet de délimiter la portée
du système, définir les frontières et identifier les interfaces. Elle donne une
vue des parties prenantes et des utilisateurs du système en recueillant leurs
besoins, besoins qui sont développés dans les cas d’utilisation. A partir de ces
derniers, les risques les plus sérieux sont identifiés et l’architecture candidate
est décrite et esquissée. Cette phase démontre que le système proposé est en
mesure de résoudre les problèmes ou de prendre en charge les objectifs fixés.
• L’élaboration : cette phase reprend les éléments de la phase de pré-étude et
les précise pour en ressortir une spécification plus détaillée de la solution
choisie. De cette spécification les principaux composants sont identifiés. Au
terme de cette phase, les chefs de projet doivent être en mesure de prévoir
les activités et d’estimer les ressources nécessaires à l’achèvement du projet.
• La construction : Elle finalise l’analyse, de la conception, de
l’implémentation et des tests. Elle permet de surveiller les risques critiques
et significatifs identifiés dans les deux premières phases et de réduire les
risques.
• La transition : Elle permet d’élaborer les manuels et les documents
concernant la version du produit. Un groupe d’utilisateurs essaye le produit
et détecte les anomalies. Cette phase suppose des activités comme la
formation des utilisateurs clients, la mise en œuvre d’un service d’assistance
et la correction des anomalies constatées.
La Processus unifié se réalise aussi au travers d’activités reparties dans les

différentes phases précitées. Ces activités sont :
• La modélisation métier : elle aide à la compréhension de la structure et de

la dynamique de l’organisation à partir des problèmes posés dans le contexte
de l’organisation, de concevoir un glossaire et d’élaborer de meilleures
solutions.
• L’expressions des besoins : l’expression des besoins permet d’abord
d’inventorier les besoins principaux et fournir une liste de leurs rôles,
ensuite de recenser les besoins fonctionnels (du point de vue de l’utilisateur)
qui conduisent à l’élaboration des modèles de cas d’utilisations et enfin
d’appréhender les besoins non fonctionnels (techniques) et livrer une liste
des exigences (ce que doit faire le système).
7
Gautier Picard, Conduite de projet Méthode d’analyse et de conception Processus Unifié, Ecole Nationale
Supérieure des Mines de Saint-Etienne, Octobre 2009, p.39-41.
14
• L’analyse et la conception : elle permet d’acquérir une compréhension
approfondie des contraintes liées au langage, à l’utilisation des composants
et au système d’exploitation. Elle consiste à transformer les besoins
utilisateurs en modèles UML. Les principaux livrables ici sont des modèles
d’analyse et des modèles de conception.
• L’implémentation : l’implémentation est le résultat de la conception pour
implémenter le système sous forme de composants, c’est-à-dire, de code
source, de scripts, de binaires, d’exécutables et d’autres éléments du même
type. Les objectifs majeurs de cette phase sont de planifier les intégrations
de composants pour chaque itération, et de produire les classes et les sous-
systèmes sous formes de codes sources.
• Le test : les tests permettent de vérifier des résultats de l’implémentation
en testant la construction. Pour mener à bien ces tests, il faut les planifier
pour chaque itération, les implémenter en créant des cas de tests, effectuer
ces tests et prendre en compte le résultat de chacun.
• Le déploiement : une fois terminé les développements sont déployés.
L’activité de déploiement peut-être dans une sous-activité de prototypage
dont l’objectif est de valider l’architecture physique, et les choix
technologiques.
• La configuration/gestion du changement, gestion de projet et gestion de
l’environnement8 : le but de la gestion de la configuration et des
changements est de tracer et de maintenir l’intégrité de l’évolution des
spécificités du projet. L’équipe en charge du projet doit être à même de
tracer l’évolution du produit, de capturer et gérer les demandes de
changement peu importe d’où elles viennent et implémenter ces
changements de façon consistante. La gestion d’un projet logiciel est l’art
de mesurer les objectifs compétitifs, de gérer le risque et les contraintes
pour fournir un produit qui rencontre les besoins des consommateurs et des
utilisateurs. Le but de l’environnement est de supporter l’organisation du
développement avec les processus et les outils.
8
Yves Wautelet et Laurent Louvigny et Manuel Kol, L’Unified Process comme méthodologie de gestion de
projet informatique, IAG- ISYS (Unité de Systèmes d’Information), Université Catholique de Louvain, p.6-7
passim
15
Figure 3 : La démarche du Processus Unifié
Comme précédemment signalé, le processus unifié s’appuie sur un cycle de vie

itératif et incrémental (figure 4). Dans cette approche, l’identification des risques
liés à un projet est forcée très tôt dans son cycle de vie, lorsqu’il est encore possible
de réagir d’une manière rapide et efficiente. Les tests se font de manière continue
et les avancées sont évaluées au fur et à mesure de l’implémentation à chaque point
de contrôle défini au préalable et nommé : jalon.
Figure 4 : Cycle de vie de PU
16
4- Déclinaison du Processus unifié
Le processus unifié étant une méthode générique puisqu’elle ne définit qu’un certain
nombre de critères de développement, plusieurs déclinaisons personnalisées selon
les besoins ont été élaborées. Ainsi, nous notons parmi les plus connus :
• Le Rational Unified Process (RUP)9 : C’est un processus de développement
logiciel. Il fournit une approche disciplinée à l’affectation des tâches et des
responsabilités au sein d’une organisation de développement. Son but est
d'assurer la production d’un logiciel de grande qualité satisfaisant les besoins
de ses utilisateurs finaux dans des délais et avec un budget prévisibles bien
qu’il manque de rapidité. Il utilise la technologie du web, de sorte qu'il est
littéralement à portée de souris des développeurs. On peut aisément
l’adapter pour accommoder les besoins particuliers d'une organisation.
Cependant le RUP est un processus commercial développé et maintenu par
Rational Software qui est parfaitement intégré à l'ensemble des outils de
développement logiciel proposés par la société, aussi est-il très couteux à
adapter ; Très axé processus, au détriment du développement : peu de place
pour le code et la technologie.
• L’Extrem Unified Process (XUP) : C’est une instanciation hybride intégrant
UP avec l’Extrem Programming regroupant les pratiques de développement
(travail en équipes, transfert de compétences…). Comme les autres variantes,
c’est un processus itératif dont la mise en œuvre est simple et qui fait une
large place aux aspects techniques : prototypes, règles de développement,
tests… Néanmoins il ne couvre pas les phases en amont et en aval au
développement : capture des besoins, support, maintenance, tests
d'intégration, fait peu cas de la phase d'analyse.
• Le Two Tracks Unified Process (2TUP)10: C'est un processus qui répond aux
caractéristiques du Processus Unifié. Le processus 2TUP apporte une réponse
aux contraintes de changement continuel imposées aux systèmes
d'information de l'entreprise. En ce sens, il renforce le contrôle sur les
capacités d'évolution et de correction de tels systèmes. « 2 Track » signifie
littéralement que le processus suit deux chemins. Il s'agit des « chemins
fonctionnels » et « d'architecture technique », qui correspondent aux deux
axes de changement imposés au système d'information. Il est itératif, fait une
large place à la technologie et à la gestion du risque et définit les profils des
intervenants, les livrables, les plans de travail, les prototypes.
Cependant il est superficiel sur les phases situées en amont et en aval du
développement : capture des besoins, support, maintenance, gestion du
changement etc., sa documentation n’est pas assez complète.
9
Philippe Kruchten, Introduction au Rational Unified Process, Editions Eyrolles, 1999, p50-80 passim.
10
Kazi Aouel Bassim et Rostane Zakaria, Suivie des enseignements du LMD par application de la méthode
2TUP, Mémoire de Fin d’Etudes pour l’obtention du Diplôme d’Ingénieur d’Etat en Informatique, Université
Abou Bekr Belkadi de Tlemcen, 2007, p 12-13.
17
II. PRÉSENTATION DE MERISE
La méthode MERISE est une méthode de conception et de développement de système
d'information informatisé. La méthode MERISE11 est basée sur la séparation des
données et des traitements à effectuer en plusieurs modèles conceptuels et
physiques. La séparation des données et des traitements assure une longévité au
modèle dans la mesure où l'agencement des données n'a pas à être souvent remanié,
tandis que les traitements le sont plus fréquemment. La méthode MERISE s’inscrit
dans trois dimensions qui sont :
− Le cycle de vie ou la démarche ;
− Le cycle d’abstraction ou le raisonnement ;
− Le cycle de décision ou la maitrise.
1- Le cycle de vie ou la démarche

La méthode MERISE propose une démarche de construction de système d’information
en 6 étapes :
• Le schéma directeur : définition de la politique de l’entreprise ;
• L’étude préalable : analyse de l’existant qui conduit à des variantes ;
• L’étude détaillée : étude approfondie de la solution choisie par la direction ;
• L’étude technique : traduction informatique des spécifications issues de
l’étude détaillée ;
• La réalisation : écriture des programmes, génération des fichiers ou bases de
données et tests ;
• La maintenance : regroupe les actions de dépannage, de réparation, de
réglages, de révision, de contrôle et d’évolution de l’application.
2- Le cycle d’abstraction ou le
raisonnement
C’est la représentation du domaine étudié, à travers plusieurs modèles suivant un
formalisme en tenant compte du niveau d’abstraction. A chaque niveau d'abstraction
correspond un modèle pour le volet statique (les données) et un autre pour le volet
dynamique (les traitements). Ces niveaux sont :
11
La méthode MERISE date de 1978-1979, et fait suite à une consultation nationale lancée en 1977 par le
ministère de l'Industrie française dans le but de choisir des sociétés de conseil en informatique afin de définir une
méthode de conception de systèmes d'information.
18
➢ Le niveau conceptuel
Que fait-on et pourquoi ? Que signifient ces informations ? Telles sont les
questions auxquelles répondent les découpages du niveau conceptuel en
faisant abstraction des contraintes d’organisation et technique. Ces niveaux
sont :
▪ Le Modèle Conceptuel de Communication (MCC) qui définir le système
et les éléments externes avec lesquels il échange des flux
d'information ;
▪ Le Modèle Conceptuel de Données (MCD) qui représente l’ensemble
des données du domaine, sans tenir compte des aspects techniques et
économiques de mémorisation et d’accès, sans se référer aux
conditions d’utilisation par tel ou tel traitement ;
▪ Le Modèle Conceptuel de Traitement (MCT) qui a pour objectif de
représenter formellement les activités exercées par le domaine.
➢ Le niveau organisationnel
Ici, l’accent est mis sur l’organisation selon la répartition des tâches entre
l’homme et la machine. La question à laquelle on répond est : « Comment
faire et avec quels moyens logiciels, humains et informatiques ? ». Il regroupe
trois (3) modèles, à savoir :
▪ Le Modèle Organisationnel de Communication (MOC) qui représente
les échanges qui ont lieu entre les sites de traitements et de données.
Il ne concerne que les communications entre sites. Il n’existe pas s’il
n’existe qu’un site ;
▪ Le Modèle Organisationnel de Données (MOD) va permettre de
prendre en compte les données du MCD des éléments relevant de la
mémorisation, permettra aussi de gérer leur accès ;
▪ Le Modèle Organisationnel de Traitement (MOT) qui consiste à
découper les opérations spécifiées au niveau conceptuel en tâches et à
construire l’enchainement chronologique des activités.
➢ Le niveau logique
Ce niveau décrit sans grande précision c’est-à-dire tenir compte de leurs
caractéristiques techniques les moyens et les ressources informatiques. Il
prend en compte trois modèles :
▪ Le Modèle Logique de Communication (MLC) qui est une
représentation des messages échangés entre site et base de données. Il
provient du MLD et de l’utilisation des outils en temps différé ;
▪ Le Modèle Logique de Données (MLD) qui donne une description des
données en considérant les moyens informatiques de mémorisation et
les conditions dans lesquelles elles seront utilisées par les traitements ;
▪ Le Modèle Logique de Traitement (MLT) qui décrit comment les tâches
informatisées définies dans le MOT sont conçues en termes de logiciel.
19
➢ Le niveau physique
Il permet de définir les aspects physiques liés aux matériels et logiciels qui
seront utilisés. Il est basé sur trois modèles :
▪ Le Modèle Physique de Communication (MPC) qui comprend la
télématique entre sites informatiques ;
▪ Le Modèle Physique des Données (MPD) qui est une représentation de
la base de données ou de l’ensemble des fichiers, exprimée dans la
syntaxe du système de gestion de bases de données (SGBD) ;
▪ Le Modèle Physique de Traitement (MPT) qui comprend les
programmes techniques et leur environnement d’exploitation,
moniteur temps réel, traitement par lot, temps partagé.
III. CHOIX DE LA MÉTHODE

La présentation des deux (2) méthodes d’analyse les plus utilisées nous a permis de
voir les différentes techniques de conceptions adoptées, faisons à nouveau une
comparaison objective de ces deux (2) méthodes d’analyse afin de choisir celle qui
est la plus adapté pour la réalisation de notre projet.
1- Comparaison PU et MERISE
Les méthodes Processus unifié + UML et Merise présentent les caractéristiques
intéressantes suivantes :
Nom de Modélisation Modélisation Gestion Gestion du Modélisation Privilèges

la des Données des des Déploiement Objet aux
Méthode Traitements Tests Interactions
Utilisateurs
MERISE
PU-UML
Tableau 1 : Comparaison MERISE-UML
20
2- Choix de la méthode
De notre analyse, il ressort que le système à mettre en place devra gérer les
interactions avec les utilisateurs tout aussi bien qu’il devra assurer le traitement des
données. Ce constat nous amène à considérer le couple Processus Unifié-UML comme
méthode de modélisation. Ce couple présente plus les fonctionnalités du système
avec notamment son diagramme de cas d’utilisation. Avec cette méthode la fonction
de notre système est vite repérée et elle offre la possibilité d’obtenir une couche
métier d’une application grâce au diagramme de classe qui précise les classes et
leurs méthodes.
Nous ne négligerons pas aussi l’aspect itératif et incrémental du couple PU-UML qui
permet de réaliser notre application fonctionnalité après fonctionnalité et reprendre
rapidement le processus de modélisation et de réalisation en prenant en compte les
exigences du client. Cet aspect nous permet l’adéquation de la solution avec la
demande.
a. Choix de la déclinaison
Les trois déclinaisons à savoir RUP, XUP et 2TUP sont intéressantes du fait qu’elles
permettent toutes de prendre en compte le facteur itération. Mais nous devons
utiliser qu’une seule déclinaison pour l’élaboration de notre projet. Nous étudierons
ces déclinaisons avant de faire notre choix.
✓ La déclinaison XUP
Nous nous séparerons de cette déclinaison pour deux raisons :
▪ Comme signifié dans la description du processus unifié plus haut, elle élude
la phase d’analyse, ce qui ne nous donne pas d’idée précise sur l’état du
futur système, on ne peut pas se permettre une telle pratique car le temps
imparti au développement de test est assez court et nécessite donc que
tout soit clairement définit au départ.
▪ Sa mise en œuvre prête très souvent à confusion car on n’a pas d’idées
claires sur les jalons et les personnes intervenant dans chaque phase du
projet.
✓ Les déclinaisons RUP et 2TUP
Les déclinaisons RUP et 2TUP sont mieux adaptées à notre projet surtout d’un point
de vue livrables et jalons d’autant plus que nous faisions très fréquemment des
versions pour les tests et les présentations. Cependant, nous choisissons
particulièrement le RUP pour sa démarche de développement en cascade qui est
mieux adapté à notre projet en termes de nombre de ressources et qui offre une
meilleure gestion des risques. En effet, le 2TUP par sa démarche en forme de Y
convient mieux aux grands projets avec de nombreuses ressources, ce qui n’est pas
notre cas. En ce qui nous concerne, les délais de livraison de la solution ne nous
permettaient pas de suivre ces deux branches (fonctionnelle et technique).
21
b. Présentation détaillée de la déclinaison RUP
La déclinaison du processus unifié choisie pour la mise en œuvre de notre système
est le RUP. Dans la présentation qui suit, nous avons surtout mis l’accent sur les
principaux apports de RUP par rapport à UP. En effet RUP étant une déclinaison de
l’UP il y a ses propriétés qu’elle possède. Le Rational Unified Process est aussi un
Framework de processus se voulant évolutif, que l'on peut adapter et étendre pour
tenir compte des besoins de l’organisation qui l'adopte. Il intègre un grand nombre
des meilleures pratiques de développement du logiciel moderne sous une forme
adaptée à un large éventail de projets et d'organisations. Nous présentons ici les
principaux apports de RUP par rapport à UP en traitant les points suivants :
➢ Les bonnes pratiques
Ces 6 pratiques sont prises en compte dans le Rational Unified Process, parmi des
dizaines d’autres :
▪ Développement itératif et incrémental ;
▪ Gestion des besoins ;
▪ Architecture et utilisation de composants ;
▪ Modélisation UML ;
▪ Qualité du processus et du produit ;
▪ Gestion de la configuration et des changements.
➢ Les phases du processus
Comme UP, RUP est un processus à deux dimensions. Il est modélisé par un schéma
articulé suivant deux axes (figure 7) :
▪ l'axe horizontal représente le temps et montre le déroulement du cycle de
vie du processus ;
▪ l'axe vertical représente les principaux enchaînements d’activités, qui
regroupent les activités selon leur nature.
22
Figure 5 : Deux dimensions du RUP
➢ Les activités du processus12

Les activités représentent des étapes dans le développement d'un logiciel, mais à un
niveau de granularité beaucoup plus fin que les phases. Chaque activité est répétée
autant de fois qu'il y a d'itérations.
Les activités spécifiques à la déclinaison RUP sont les suivantes :
▪ Modélisation métier : La modélisation métier permet de décrire la structure
et la dynamique de l'organisation dans laquelle le système est déployé. Elle
aide à appréhender les problèmes courants dans l’organisation et d’identifier
les améliorations potentielles afin de garantir que les clients, les utilisateurs
finaux et les développeurs partagent une vision commune de l'organisation.
Cette modélisation permet aussi de réaliser une base d'informations qui
contiendra le cahier des charges du produit et la planification des tâches de
l’organisation.
▪ Gestion des exigences : La gestion des exigences a pour but d’établir et de
maintenir les accords avec les clients et autres stakeholders sur ce que le
système doit faire. Elle permet de procurer aux développeurs une meilleure
compréhension des besoins du système tout en définissant les limites du
système. Elle donne une base pour planifier le contenu technique des
itérations ainsi qu’une base pour estimer le coût et le temps pour développer
le système. Pour finir elle définit et construire une maquette de l'interface
utilisateur basée sur les exigences et les buts de celui-ci.
12
Yves Wautelet et Laurent Louvigny et Manuel Kolp, Le unified process comme méthodologie de
gestion de projet informatique Eléments d’application en milieu sidérurgique, IAG- ISYS (Unité de Systèmes
d’Information), Université Catholique de Louvain, p 6-7 passim.
23
▪ Analyse et conception : L’analyse et la conception ont pour but de
comprendre le cahier des charges et d’écrire les spécifications internes qui
décrivent comment implémenter le système. L'analyse permet d'obtenir une
vue interne idéale du système. Un de ces objectifs non négligeable est la
conception qui définir une architecture robuste du système qui recouvre
entièrement les besoins de celui-ci. Elle fournit une analyse qui se concentre
sur le « quoi faire », la conception se concentre sur le « comment le faire ».
▪ Implémentation : L’implémentation se concentre sur la définition de
l’organisation du code en termes de sous-systèmes d’implémentation
organisés en couches. Elle se charge aussi d’implémenter classes et objets en
termes de composants et de tester les composants développés comme des
unités sans oublier d’intégrer dans un système exécutable les résultats
produits par des programmeurs individuels ou des équipes ;
▪ Tests : La phase de test a pour objectif d'évaluer le niveau de qualité atteint
par le produit et d'en tirer les conclusions. Ceci ne comprend pas uniquement
le produit fini, mais commence tôt dans le projet avec la validation de
l’architecture et continue à travers la validation du produit fini au
consommateur.
▪ Déploiement : Le but des activités de déploiement est de livrer le produit aux
utilisateurs finaux.
24
CHAPITRE IV : CONCEPTION DU
SYSTÈME
I. DÉFINITION ET ANALYSE DES

BESOINS
La phase de définition et d’analyse des besoins (ou pré-étude) est la première phase
de notre processus de développement. Elle a pour objectif le repérage des besoins
fonctionnels et opérationnels et est basée sur du texte ou des diagrammes très
simples. Elle prépare les activités plus formelles de capture de besoins fonctionnels
et de capture de besoins techniques. Elle est constituée de 3 phases :
− Identification des acteurs ;
− Identification des messages ;
− Identification des cas d’utilisation.
1- Identification des acteurs

Pour trouver les acteurs d’un système, il faut avant tout pouvoir identifier quels sont
les différents rôles que vont devoir jouer ces utilisateurs. Ensuite, il faut s’intéresser
aux autres systèmes avec lesquels le système va devoir communiquer. Enfin, une fois
ces tâches effectuées, nous avons pu identifier les acteurs susceptibles d’interagir
avec l’application :
• Les membres : c’est tous les mutualistes.
• Les membres de la trésorerie : ce sont des mutualistes chargés de la gestion
des entrées et sorties de fonds dans la caisse. On distingue le trésorier général
et son adjoint.
• Le président du bureau exécutif : c’est la personne qui représente la
mutuelle, elle est responsable de l’exécution des décisions adoptées en
Assemblée Générale et est ordonnateur des dépenses approuvées par le
Comité de Surveillance et de Contrôle.
• Les membres du comité de surveillance et de contrôle : composé de cinq
(05) membres, Ils font office de commissariat au compte.
• Les membres du secrétariat général : Il s’agit des personnes chargées de la
gestion administrative de la mutuelle. Le secrétariat général est composé du
secrétaire général et de son adjoint.
• Les partenaires : Ce sont les boutiques, magasins, entreprises immobilières
etc. Entité physique ou morale avec qui la Mu.P.I a signé un partenariat.
• L’administrateur : C’est la personne chargée de créer les profils utilisateurs,
d’attribuer les droits d’accès et de maintenir le système dans un bon état.
25
2- Identification des messages
La principale tâche ici, consiste à énumérer les différents messages13 échangés entre
le système et tous les acteurs identifiés précédemment. Tous ces acteurs peuvent
être représentés de façon synthétique sur le diagramme de contexte statique.
a. Diagramme de contexte statique

Le diagramme de contexte statique permet de positionner le système dans son
environnement selon le point de vue matériel. Le système est donc décrit
physiquement, et non pas en termes de fonctionnalités. De plus, pour chaque type
d’éléments matériels extérieurs au système, il est précisé le nombre maximal et
minimal d’éléments, appelé cardinalité, qui sont mis en jour.
Figure 6 : Diagramme de contexte statique
13
Un message est la représentation d’une communication unidirectionnelle entre les objets qui transporte de
l’information avec l’intention de déclencher une activité chez le récepteur.
26
b. Les messages et leur description
Le tableau 2 est un récapitulatif des messages échangés entre le système et les
acteurs externes.
Message Description
Messages émis par le système
1 Présenter l’interface d’un utilisateur
2 Générer fichier en PDF, XLS, DOCX
3 Envoyer des notifications
4 Générer et présenter un bilan financier
5 Présenter l’interface d’inscription et de connexion
6 Présenter des informations d’erreur
7 Présenter des annonces
8 Présenter des rapport et procès-verbaux
9 Afficher les transactions financières avec la trésorerie
10 Afficher les opérations effectuées chez les partenaires
11 Présenter les informations de description des membres
12 Présenter les activités, prestations, projets
13 Présenter des statistiques
14 Afficher les plaintes des membres
15 Présenter les utilisateurs, leurs profils et leurs droits
27
Messages reçus par le système
16 Gérer un utilisateur, un profil et attribuer un droit
17 Editer une activité, une prestation, un projet
18 Editer une transaction avec la trésorerie
19 Editer une opération avec un partenaire
20 Envoyer sa plainte
21 Editer et publier une annonce
22 Suivi des prestations, activités, projets
23 Suivi des transactions avec la trésorerie
24 Suivi des opérations avec les partenaires
25 Suivi des procès-verbaux et des rapports
26 Suivi du bilan financier
27 Suivi des statistiques
28 Publier le bilan financier
29 Editer les compétences pour un membre
Tableau 2 : Liste des messages entre le système et les acteurs externes
3- Identification des cas utilisation

Un cas d’utilisation désigne une fonctionnalité visible à l’extérieur du système dont
on désire décrit le fonctionnement. Il décrit les possibilités d’interactions
fonctionnelles entre le système et les acteurs et permet de définir les limites et les
relations entre le système et son environnement. Il est destiné à structurer les
besoins des utilisateurs et les objectifs par rapport au système. En considérant les
besoins de l’utilisateur nous obtenons les cas d’utilisation ci-dessous :
28
Cas d’utilisation Acteurs impliqués
Créer compte Utilisateur, Administrateur
Publier message Utilisateur
Consulter message Utilisateur
Consulter opération Utilisateur
Authentification Utilisateur
Enregistrer opération Partenaire
Enregistrer compétence Membre
Modifier compétence Membre
Consulter compétence Membre
Consulter partenaire Membre
Suivi du fonctionnement Membre administratif
Consulter les statistiques Président
Enregistrer une action Secrétaire Général
Modifier une action Secrétaire Général
Supprimer une action Secrétaire Général
Modifier une transaction Membre du Comité de Surveillance et de Contrôle
Supprimer une transaction Membre du Comité de Surveillance et de Contrôle
Enregistrer une transaction Trésorier
Attribuer droit Administrateur
Supprimer utilisateur Administrateur
Tableau 3 : Les cas d'utilisation
a. Le diagramme des cas d’utilisation
29
Figure 7 : Diagramme des cas d'utilisation
30
b. La description textuelle de chaque cas
d’utilisation
À chaque cas d’utilisation doit être associée une description textuelle des
interactions entre l’acteur et le système et les actions que le système doit réaliser
en vue de produire les résultats attendus par les acteurs.
La description textuelle d’un cas d’utilisation est articulée en six points14 :
• Objectif : Décrire succinctement le contexte et les résultats attendus du cas
d’utilisation.
• Acteurs concernés : Le ou les acteurs concernés par le cas doivent être
identifiés en précisant globalement leur rôle.
• Pré conditions : Si certaines conditions particulières sont nécessaires avant
l’exécution du cas, elles sont à exprimer à ce niveau.
• Post conditions : Par symétrie, si certaines conditions particulières doivent
être réunies après l’exécution du cas, elles sont à exprimer à ce niveau.
• Scénario nominal : Il s’agit là du scénario principal qui doit se dérouler sans
incident et qui permet d’aboutir au résultat souhaité.
• Scénarios alternatifs : Les autres scénarios, secondaires ou correspondants à
la résolution d’anomalies, sont à décrire à ce niveau. Le lien avec le scénario
principal se fait à l’aide d’une numérotation hiérarchisée (1.1a, 1.1b…)
rappelant le numéro de l’action concernée.
NB : Chaque description textuelle de cas d’utilisation sera suivie du diagramme de
séquence associée dudit cas d’utilisation.
14
Joseph Gabay et David Gabay,UML 2 Analyse et conception,Paris,Dunod,2008, p 73-124 passim ; Laurent
Audibert, UML 2.0, Institut Universitaire de Technologie de Villetaneuse – Département Informatique, Paris 13, p 67-67.
31
➢ Cas : Attribuer droit
Nom Attribuer droit
Acteurs Principal : administrateur
Pré conditions (a) administrateur déjà authentifié
(b) compte utilisateur déjà créé
Scénario Scénario nominal
1 Le système présente un menu
2 L’administrateur clic l’option « attribuer droit »
3 Le système présente une liste des utilisateurs
4 L’administrateur clic sur un utilisateur
5 Le système présente une liste des droits
6 L’administrateur choisit les différents droits
7 Le système enregistre les différents droits sélectionnés
par l’administrateur pour le compte de l’utilisateur
sélectionné
8 Le système informe l’administrateur de la réussite de
l’attribution de droit
Scénario alternatif
Post conditions Action enregistrée plus disponibles
Tableau 4 : Description textuelle de cas d’utilisation "Attribuer droit"
32
Figure 8 : Diagramme de séquences du cas d'utilisation "attribuer droit"
33
➢ Cas : authentification
Nom Authentification
Acteurs Principal : utilisateur
Pré conditions (a) compte utilisateur déjà créé
1 Le système présente un menu d’inscription
2 L’utilisateur clic l’option « authentification »
3 Le système présente un formulaire d’authentification
contenant les champs « nom utilisateur » et « mot de
passe »
4 L’utilisateur renseigne son nom d’utilisateur et son mot
de passe
5 Le système vérifie son nom utilisateur et son mot de
passe
6 Le système ouvre la session correspondant au compte
utilisateur
Point 5 : nom 5(a) Le système affiche le formulaire
d’utilisateur et de connexion
mot de passe
incorrecte
Tableau 5 : Description textuelle du cas d’utilisation "authentification"
Figure 9: Diagramme de séquences du cas d'utilisation "Authentification"
34
➢ Cas : Consulter message
Nom Consulter message

Acteurs Principal : Utilisateur
Pré conditions (a) Utilisateur déjà authentifié
(b) Notification de message déjà arrivé
1 L’utilisateur clique sur l’option « consulter message »
2 Le système affiche la liste des messages
3 L’utilisateur clique sur un message
4 Le système présente le contenu du message à
l’utilisateur
Post conditions Message disponible en consultation
Tableau 6 : Description textuelle du cas d’utilisation "consulter message"
Figure 10 : Diagramme de séquences du cas d’utilisation "consulter message"
35
➢ Cas : Consulter compétences
Nom Consulter compétences

Acteurs Principal : membre
Pré conditions (a) membre déjà authentifié
(b) compétences déjà enregistrées
2 Le membre clic sur le menu de consultation des
compétences
3 Le système présente au membre le formulaire
contenant les champs selon lesquels le membre a
enregistrés ses compétences
4 Le membre choisit un champ
5 Le système affiche les informations contenues dans le
champ choisi par le membre
Post conditions Compétences disponibles à la consultation
Tableau 7 : Description textuelle du cas d’utilisation "consulter compétences"
Figure 11 : Diagramme de séquences du cas d'utilisation "consulter compétences"
36
➢ Cas : Consulter opération
Nom Consulter opération

(b) Opérations déjà enregistrées
2 L’utilisateur clic l’option «
consulter opération »
3 Le système présente la liste des
opérations à l’utilisateur
4 L’utilisateur clic sur une
opération
5 Le système affiche les
informations de l’opération
Post conditions Opérations disponibles en consultation
Tableau 8 : Description textuelle du cas d’utilisation "consulter opération"
Figure 12 : Diagramme de séquences du cas d'utilisation "consulter opération"
37
➢ Cas : Créer compte
Nom Créer compte

Secondaire : Administrateur
Pré conditions (a) Système opérationnel
(b) administrateur déjà authentifié
1 Le système présente le menu d’inscription
2 L’utilisateur remplit le formulaire d’inscription avec
acceptation de prélèvement à la source puis le valide
3 Le système vérifie les informations enregistrées par
l’utilisateur
4 Le système envoie un message qui signale une
demande de création de compte à l’administrateur
5 L’administrateur clic sur le message
6 Le système présente le formulaire de création de
l’utilisateur
7 L’administrateur clic sur le bouton créer compte
8 Le système enregistre le compte avec les informations
de l’utilisateur contenues dans le formulaire
d’inscription et envoie un mail de succès à l’utilisateur
Point 3: formulaire 3a Le système redemande de bien
mal rempli saisir le différent champ du
formulaire
Post conditions Nouvel utilisateur dans le système
Tableau 9 : Description textuelle du cas d’utilisation "créer compte"
38
Figure 13 : Diagramme de séquences du cas d'utilisation "créer compte"
39
➢ Cas : Enregistrer action
Nom Enregistrer une action (activité, projet, prestation)

Acteurs Principal : secrétaire général
Pré conditions (a) secrétaire général déjà authentifié
2 Le secrétaire général clic l’option « enregistrer action »
3 Le système présente un menu avec les options «
activité », « projet », « prestation »
4 Le secrétaire général choisit une option
5 Le système présente un formulaire d’enregistrement
d’activités soit de projets soit de prestations selon
l’option choisie par le secrétaire général
6 Le secrétaire général renseigne le formulaire présenté
selon l’option choisie puis valide le formulaire
7 Le système vérifie les informations renseignées
8 Le système enregistre les informations du formulaire
9 Le système informe le secrétaire général du succès de
l’enregistrement
Point 7 : non 7a Le système réaffiche le formulaire
validité des d’enregistrement de l’action
informations sélectionné en signalant une erreur
renseignées dans le
formulaire
Post conditions Action enregistrée disponibles
Tableau 10 : Description textuelle du cas d’utilisation "enregistrer action"
40
Figure 14 : Diagramme de séquences du cas d'utilisation "enregistrer action"
41
➢ Cas : Enregistrer compétences
Nom Enregistrer compétences

2 Le membre clic l’option « enregistrer compétences »
3 Le système présente le formulaire d’enregistrement des
compétences au membre
4 Le membre choisit le nombre de champs selon lesquels
il souhaite décrire ses compétences
5 Le système affiche les différents champs selon lesquels
le membre souhaite décrire ses compétences
6 Le membre renseigne les champs puis valide le
formulaire
7 Le système vérifie les informations saisies dans le
formulaire
9 Le système informe le membre de la réussite de
l’enregistrement
Point 7: non 7a Le système réaffiche le formulaire
validité des d’enregistrement de compétences
informations en signalant une erreur
formulaire
Post conditions Nouvelles informations de compétences
Tableau 11 : Description textuelle du cas d’utilisation "enregistrer compétences"
42
Figure 15 : Diagramme de séquences du cas d'utilisation "enregistrer compétences"
43
➢ Cas : Enregistrer opération
Nom Enregistrer opération

Acteurs Principal : partenaire
Pré conditions (a) Partenaire déjà authentifié
(b) le membre a un code d’opération
2 Le partenaire clic l’option « enregistrer opération »
3 Le système présente au partenaire le formulaire
d’enregistrement d’une opération
4 Le partenaire remplir le formulaire puis le valide
5 Le système vérifie les informations renseignées dans le
formulaire
6 Le système enregistre les informations de l’opération
7 Le système génère le code d’opération du membre
8 Le système informe le partenaire du succès
l’enregistrement de l’opération
Point 5: non validité 5a Le système réaffiche le formulaire
des informations d’enregistrement de l’opération
renseignées dans le en signalant une erreur
formulaire
Post conditions Nouvelle opération enregistrée
Tableau 12 : Description textuelle du cas d’utilisation "enregistrer opération"
44
Figure 16 : Diagramme de séquences du cas d'utilisation "enregistrer opération"
45
➢ Cas : Enregistrer transaction
Nom Enregistrer transaction

Acteurs Principal : membre de la trésorerie
Pré conditions (a) membre de la trésorerie déjà authentifié
(b) action déjà enregistrée
2 Le membre de la trésorerie clic l’option « enregistrer
transaction »
3 Le système présente un formulaire d’enregistrement
d’une transaction
4 Le membre de la trésorerie renseigne le formulaire puis
le valide
formulaire
6 Le système enregistre les informations renseignées dans
le formulaire
7 Le système informe le membre de la trésorerie de la
réussite de l’enregistrement
validité des d’enregistrement de la transaction
formulaire
Tableau 13 : Description textuelle du cas d’utilisation "enregistrer transaction"
46
Figure 17 : Diagramme de séquences du cas d'utilisation "enregistrer transaction"
47
➢ Cas : Modifier action
Nom Modification une action (activité, projet, prestation)

2 Le secrétaire général clic l’option « modifier action »
4 Le membre administratif choisit une option
5 Le système présente une liste d’activités ou de projets
ou de prestations selon l’option choisie par le
secrétaire général
6 Le secrétaire général clic sur un élément de la liste
7 Le système présente dans un formulaire de modification
contenant les informations de l’élément sélectionné
8 Le secrétaire général modifie les informations du
formulaire
formulaire
11 Le système informe le secrétaire général du succès de
la modification
point 9 : non 9a Le système réaffiche le formulaire
validations des de modification de l’action
informations sélectionné en signalant une erreur
renseignées dans
le formulaire
Post conditions
Tableau 14 : Description textuelle du cas d’utilisation "modifier action"
48
Figure 18 : Diagramme de séquences du cas d'utilisation "modifier action"
49
➢ Cas : Modifier compétences
Nom Modifier compétences

(b) compétences déjà enregistrées
2 Le membre clic l’option « modifier compétences »
3 Le système présente le formulaire d’enregistrement des
compétences au membre
4 Le membre choisit le champ qu’il souhaite modifier
5 Le système affiche les informations du champ choisi
par le membre
6 Le membre renseigne le champ puis valide le formulaire
7 Le système vérifie les informations saisies dans le
formulaire
9 Le système informe le membre de la réussite de la
modification
Point 7: non 7a Le système réaffiche le formulaire
validation des d’enregistrement de compétences
renseignées dans
le formulaire
Post conditions Nouvelles informations de compétences
Tableau 15 : Description textuelle du cas d’utilisation "modifier compétences"
50
Figure 19 : Diagramme de séquences du cas d'utilisation "modifier compétences"
51
➢ Cas : Modifier transaction
Nom Modifier une transaction

Acteurs Principal : membre du CSC
Pré conditions (a) membre du CSC déjà authentifié
(b) transaction déjà enregistrée
2 Le membre du CSC clic l’option « modifier transaction »
3 Le système présente une liste de transaction
4 Le membre du CSC clic sur une transaction
5 Le système présente un formulaire de modification
contenant déjà les informations de la transaction
sélectionnée
6 Le membre du CSC modifie le formulaire puis le valide
formulaire
8 Le système enregistre les informations renseignées dans
le formulaire
9 Le système informe le membre de la trésorerie de la
réussite de l’enregistrement
validation des de modification de la transaction
renseignées dans
le formulaire
Tableau 16 : Description textuelle du cas d’utilisation "modifier transaction"
52
Figure 20 : Diagramme de séquences du cas d'utilisation "modifier transaction"
53
➢ Cas : Publier un message
Nom Publier message

2 L’utilisateur choisit l’option « publier message »
3 Le système présente un formulaire de publication de
message à l’utilisateur
4 L’utilisateur remplit le formulaire puis le valide
5 Le système enregistre le message
6 Le système envoie le message
7 Le système signale à l’utilisateur le succès de l’envoie
du message
Point 6: message 6a Le système réaffiche le formulaire
non transmis de publication de message en
signalant l’échec de l’envoi
Post conditions Message enregistré dans le système
Tableau 17 : Description textuelle du cas d’utilisation "publier message"
54
Figure 21 : Diagramme de séquences du cas d'utilisation "publier message "
55
➢ Cas : Suivi du fonctionnement
Nom Suivi du fonctionnement

Acteurs Principaux : président, secrétaire général, membres du CSC,
membre de la trésorerie
Pré conditions (a) acteur déjà authentifié
(b) les actions (activités, prestations, projets), les
transactions déjà enregistrés
2 Le membre administratif clic l’option « suivi du
fonctionnement »
activité », « projet », « prestation », « transaction »
4 Le membre administratif choisit une option
5 Le système présente une liste d’activités soit de
projets soit de prestations soit de transactions selon
l’option choisie par le membre administratif
6 Le membre administratif choisit un élément de la liste
présentée
7 Le système affiche les informations de l’élément
sélectionné
Post conditions
Tableau 18 : Description textuelle du cas d’utilisation "suivi du fonctionnement"
56
57
Figure 22 : Diagramme de séquences du cas d'utilisation "suivi du fonctionnement"
➢ Cas : Supprimer action
Nom Supprimer une action (activité, projet, prestation)

2 Le secrétaire général clic l’option « supprimer action »
4 Le secrétaire général choisit une option
5 Le système présente une liste d’activités ou de projets
ou de prestations selon l’option choisie par le
secrétaire général
6 Le secrétaire général clic sur un élément de la liste
7 Le système demande confirmation de suppression
8 Le secrétaire général confirme la suppression
9 Le système supprime l’élément sélectionné
10 Le système informe le secrétaire général de la réussite
de la suppression
Post conditions Action enregistrée non plus disponibles
Tableau 19 : Description textuelle du cas d’utilisation "supprimer action"
58
Figure 23 : Diagramme de séquences du cas d'utilisation "supprimer action"
59
➢ Cas : Supprimer transaction
Nom Supprimer une transaction

Acteurs Principal : membre du CSC
Pré conditions (a) membre du CSC déjà authentifié
(b) transaction déjà enregistrée
2 Le membre du CSC clic l’option « supprimer transaction »
5 Le système présente une liste de transactions
6 Le membre du CSC clic sur un élément de la liste
8 Le membre du CSC confirme la suppression
9 Le système supprime l’élément sélectionné
10 Le système informe le membre du CSC de la réussite de
la suppression
Post conditions Action enregistrée non plus disponibles
Tableau 20 : Description textuelle du cas d’utilisation "supprimer transaction"
60
Figure 24 : Diagramme de séquences du cas d'utilisation "supprimer transaction"
61
➢ Cas : Supprimer utilisateur
Nom Supprimer un utilisateur

Acteurs Principal : administrateur
Pré conditions (a) administrateur déjà authentifié
(b) compte utilisateur déjà créé
2 L’administrateur clic l’option « supprimer utilisateur »
3 Le système présente une liste des utilisateurs
4 L’administrateur clic sur un utilisateur
6 L’administrateur confirme la suppression
7 Le système supprime le compte de l’utilisateur
8 Le système informe l’administrateur de la réussite
de l’ suppression
Tableau 21 : Description textuelle du cas d’utilisation "supprimer utilisateur"
62
Figure 25 : Diagramme de séquences du cas d'utilisation "supprimer utilisateur"
63
II. DÉVELOPPEMENT DU MODÈLE
STATIQUE : DIAGRAMME DE
CLASSE
Le diagramme de classe constitue l’un des pivots essentiels de la modélisation avec
UML. Alors que le diagramme de cas d’utilisation montre un système du point de vue
des acteurs, le diagramme de classes en montre la structure interne. Il s’agit d’une
vue statique car on ne tient pas compte du facteur temporel dans le comportement
du système. Cette représentation est basée sur les concepts de classe et
d’association. Chaque classe se décrit par les données et les traitements dont elle
est responsable pour elle-même et vis-à-vis des autres classes. Les traitements sont
matérialisés par des opérations. Le détail des traitements n’est pas représenté
directement dans le diagramme de classe ; seul l’algorithme général et le
pseudocode correspondant peuvent être associés à la modélisation. La description
du diagramme de classe est fondée sur :
• le concept d’objet ;
• le concept de classe comprenant les attributs et les opérations ;
• les différents types d’association entre classes.
Nous présentons donc ici le diagramme de classe sous plusieurs paquetages. Un
paquetage permettant ici de regrouper les classes métiers qui concourent à certaines
fonctionnalités précises.
64
Figure 26 : Paquetage Utilisateur du diagramme de classe
65
Figure 27 : Paquetage Membre du diagramme de classe
66
Figure 28 : Paquetage Opération du diagramme de classe 67
Figure 29 : Paquetage Suivi du diagramme de classe 68
PARTIE 3
ÉTUDE TECHNIQUE ET
RÉALISATION
Cette partie présentera en premier lieu les choix techniques effectués pour
l’implémentation de notre solution informatique ainsi que les raisons qui
justifient ces choix. Un second volet présentera la solution informatique
implémentée ainsi que certains aspects non négligeables inhérents à la réalisation
d’une application.
69
CHAPITRE V : CHOIX DES TECHNIQUES
DE MISE EN OEUVRE
La réalisation d’un projet si ce dernier ne fait pas l’objet d’une étude
minutieuse notamment quant au choix des solutions de mise en œuvre, peut
entrainer des charges inutiles et de gaspillage pour les entreprises. Dans cette partie
nous allons mener une étude comparative des différentes solutions possibles pour
notre projet et sélectionner celle qui nous semble la mieux adaptée.
I. ARCHITECTURE DE LA SOLUTION
1- Présentation des architectures
En règle générale, une application informatique peut être découpée en trois niveaux
d'abstraction distincts (voir figure 31) :
• La couche de présentation, encore appelée interface homme-machine (IHM),
permet l’interaction de l’application avec l’utilisateur. Cette couche gère les
saisies au clavier, à la souris, et à la présentation des informations à l’écran.
Dans la mesure du possible, elle doit être conviviale et ergonomique ;
• La logique applicative, les traitements, décrivant les travaux à réaliser par
l’application. Ils peuvent être découpés en deux familles :
o Les traitements locaux, regroupant les contrôles effectués au niveau
du dialogue avec l'IHM, visant essentiellement le contrôle et l'aide à la
saisie ;
o Les traitements globaux, constituant l’application elle-même. Cette
couche appelée Business Logic ou couche métier, contient les règles
internes qui régissent une entreprise donnée.
• Les données, encore plus exactement l'accès aux données, regroupant
l'ensemble des mécanismes permettant la gestion des informations stockées
par l'application.
70
Figure 30 : Les trois niveaux d'architecture d'une application informatique
Ces trois niveaux pouvant être imbriqués ou repartis de différentes manières entre
plusieurs machines, leur découpage et leur répartition permettent de distinguer
plusieurs architectures applicatives.
• L’architecture un tiers ;
• L’architecture deux tiers ;
• L’architecture trois tiers.
a. Architecture un tiers15
Dans une application un tiers, les trois couches applicatives sont intimement liées et
s’exécutent sur le même ordinateur. Nous ne parlons pas ici d’architecture client-
serveur, mais d’informatique centralisée.
Dans un contexte multiutilisateur, on peut rencontrer deux types d’architecture
mettant en œuvre des applications un tiers :
− des applications sur site central (mainframe) ;
− des applications réparties sur des machines indépendantes communiquant par
partage de fichiers.
Historiquement, les applications sur site central furent les premières à proposer un
accès multi utilisateurs. Les utilisateurs se connectent aux applications exécutées
par le serveur central (le mainframe) à l’aide de terminaux passifs se comportant en
esclaves. C’est le serveur central qui prend en charge l’intégralité de traitements, y
compris l’affichage qui est simplement déporté sur des terminaux passifs.
15
Rémi LEBLOND, Vers une architecture n-tiers, Oral probatoire, 02/12/1999, P 1- 4 Passim.
Source : http://remi.leblond.free.fr/probatoire/node5.html
71
Figure 31 : Architecture d’une application sur site central
Cependant avec l’arrivée dans l’entreprise des premiers ordinateurs personnels en

réseau, il est devenu possible de déployer une application sur plusieurs ordinateurs
indépendants (application un tiers déployé). Dans ce cadre, plusieurs utilisateurs se
partagent des fichiers de données stockées sur un serveur commun. Le moteur de
base de données est exécuté indépendamment sur chaque poste client. La gestion
des conflits d’accès aux données doit être prise en charge par chaque programme de
façon indépendante.
b. Architecture deux tiers

Dans une architecture deux tiers, encore appelée client-serveur de données, le poste
client attribue le rôle de gestion, stockage et de traitement de données à un service
spécialisé : le serveur.
Ce type d'application permet de maximiser le rendement quant à la puissance des
ordinateurs déployés en réseau fournissant à l'utilisateur une interface riche, tout
en garantissant la cohérence des données, qui restent gérées de façon centralisée.
Le modèle client-serveur peut donc se résumer en un dialogue entre un client qui
effectue une demande de services et un serveur qui écoute le client et répond aux
services demandés par ce dernier.
72
Figure 32 : Dialogue client-serveur
Le client provoque l'établissement d'une conversation afin d'obtenir des données ou

un résultat de la part du serveur :
Figure 33 : Accès aux données en mode client serveur
Cet échange de messages transite à travers le réseau reliant les deux machines. Il
met en œuvre des mécanismes relativement complexes qui sont, en général, pris en
charge par un middleware16. C'est un ensemble de services logiciels construits au-
dessus d'un protocole de transport afin de permettre l'échange de requête/réponse
entre le client et le serveur de manière transparente.
16
Le Gartner Group définit le middleware comme une interface de communication universelle entre processus.
73
Figure 34 : Positionnement du middleware entre client et serveur
c. L’architecture trois tiers

L’architecture trois tiers applique les principes suivants :
− Les données sont toujours gérées de façon centralisée ;
− La présentation est toujours prise en charge par le poste client ;
− La logique applicative est prise en charge par un serveur intermédiaire.
Par conséquent, cette architecture appelée encore client-serveur de deuxième
génération ou client-serveur distribué sépare l’application en trois niveaux de
services distincts :
• premier niveau : l’affichage et les traitements locaux (contrôles de saisie,
mise en forme de données…) sont pris en charge par le poste client ;
• deuxième niveau : les traitements applicatifs globaux sont pris en charge par
le service applicatif ;
• troisième niveau : les services de base de données sont pris en charge par un
système de gestion de base de données (SGBD).
Tous ces niveaux étant indépendants, ils peuvent être implantés sur des machines
différentes, de ce fait :
− le poste client ne supporte plus l'ensemble des traitements, il est moins
sollicité et peut être moins évolué, donc moins coûteux ;
− les ressources présentes sur le réseau sont mieux exploitées, puisque les
traitements applicatifs peuvent être partagés ou regroupés (le serveur
d'application peut s'exécuter sur la même machine que le SGBD) ;
− la fiabilité et les performances de certains traitements se trouvent améliorées
par leur centralisation ;
− il est relativement simple de faire face à une forte montée en charge, en
renforçant le service applicatif.
74
Figure 35 : Architecture 3-tiers
Dans le cadre d’une application web, le poste client prend la forme d’un navigateur,
le service applicatif est assuré par un serveur HTTP et la communication avec le
SGBD met en œuvre des mécanismes bien connus des applications client-serveur de
la première génération.
Nous avons aussi, une nette distinction entre deux tronçons de communication
indépendants et délimités par le serveur HTTP.
− le premier tronçon relie le poste client au serveur Web pour permettre
l'interaction avec l'utilisateur et la visualisation des résultats. On l'appelle
circuit froid et n'est composé que de standards (principalement HTML et
HTTP). Le serveur web tient le rôle de « façade HTTP » ;
− le deuxième tronçon permet la collecte des données, il est aussi appelé circuit
chaud. Les mécanismes utilisés sont comparables à ceux mis en œuvre pour
une application deux tiers. Ils ne franchissent jamais la façade HTTP, et de ce
fait, peuvent évoluer sans impacter la configuration des postes clients.
d. Comparaison et choix des architectures

Afin de choisir une architecture pour l’application, nous avons procédé à une étude
comparée des différentes architectures précédemment présentées. Notre étude se
base sur les avantages et les inconvénients des différentes architectures :
• L’architecture un tiers (mainframe) : Ce type d'organisation est facile à
administrer. En plus d’une haute disponibilité, il dispose d’une large gamme
d'outils de conception, de programmation et d'administration assez fiable leur
permettant encore de soutenir la comparaison avec des solutions beaucoup
plus modernes. De plus, la centralisation de la puissance sur une seule et
même machine permet une utilisation optimale des ressources et se prête très
bien à des traitements par lots.
Cependant il présente une interface utilisateur en mode caractère et le
revamping (rhabillage d'application centralisée) une fois appliquée sur elle
donne une lourdeur aux interfaces graphiques.
75
• L’architecture un tiers (les applications un tiers déployés) : Ce type de
programme est simple à concevoir et à mettre en œuvre. Il existe pour cela
de nombreux environnements de développement (dBase, Ms Access, Lotus
Approach, Paradox...). L'ergonomie des applications mises en œuvre, basée
sur celle des outils bureautiques, est très riche. Ce type d'application peut
être très satisfaisant pour répondre aux besoins d'un utilisateur isolé et sa
mise en œuvre dans un environnement multi-utilisateur est envisageable.
Dans ce contexte, plusieurs utilisateurs se partagent des fichiers de données
stockés sur un serveur commun, le moteur de base de données s’exécutant de
façon indépendante sur chaque poste. Aussi lors de l'exécution d'une requête,
l’ensemble des données nécessaires doit circuler sur le réseau et on arrive
vite à la saturation de ce dernier. De plus, la cohabitation de plusieurs
moteurs de base de données indépendants manipulant les mêmes données
peut devenir assez instable à cause de conflits lors de la consultation ou de la
modification simultanée d'un même enregistrement par plusieurs utilisateurs.
Comme conséquence, ces conflits peuvent altérer l'intégrité des données.
Enfin, il est difficile d'assurer la confidentialité des données alors cette
solution est donc à réserver à des applications non critiques exploitées par de
petits groupes de travail (une dizaine de personnes au maximum).
• L’architecture deux tiers : l'architecture deux tiers présente de nombreux
avantages qui lui permettent de présenter un bilan globalement positif :
o elle permet l'utilisation d'une interface utilisateur riche ;
o elle permet l'appropriation des applications par l'utilisateur ;
o elle a introduit la notion d'interopérabilité ;
o elle utilise des middlewares.
Bien qu’ayant des avantages, l’architecture possède des inconvénients non
négligeables :
o le poste client supporte la grande majorité des traitements applicatifs ;
o du fait de sa forte sollicitation, le poste client devient de plus en plus
complexe et doit être mis à jour régulièrement pour répondre aux
besoins des utilisateurs ;
o la résolution des problèmes de montée en charge dépend
essentiellement des capacités du SGBD ;
o le manque de modularité lorsque toute la logique d’application se
trouve sur le poste client ne facilite pas la maintenance et la
réutilisation.
• L’architecture trois tiers : Douée d’une plus grande flexibilité et souplesse,
cette architecture assure une sécurité accrue, car la sécurité peut être définie
indépendamment pour chaque service et à chaque niveau, tout en
garantissant de meilleures performances, étant donné le partage des tâches
entre les différents serveurs. Bonne fiabilité, disponibilité et une excellente
évolutivité, la centralisation de la logique applicative dans cette architecture
se fait en grande partie sur un serveur HTTP ce qui soulage le poste client,
car il ne prend en charge que la présentation et les contrôles de saisie.
76
Cependant les solutions mises en œuvre sont relativement complexes à
maintenir et la gestion des sessions est compliquée. Le serveur HTTP étant la
base de cette architecture, il n’est pas rare qu’il se trouve fortement sollicité
et il est difficile de répartir la charge entre client et serveur. De plus la
réduction de la charge du serveur passe par la mise en œuvre de plusieurs
serveurs d’applications.
Architecture Sécurité Optimisation Richesse de Simplicité

des ressources l’interface d’administration
utilisateur
Un tiers
Deux tiers
Trois tiers
Tableau 22 : Résumé comparatif des architectures
Au vu du tableau ci-dessus, et compte tenu du cadre professionnel et institutionnel

du projet, notre choix s’est porté sur une architecture trois tiers puisqu’elle offre
une grande marge d’évolution et est assez flexible. Nous pouvons compter aussi au
nombre des motivations de ce choix, la possibilité d’appliquer une sécurité à tous
les niveaux de manière indépendantes, la réduction des charges du poste client ce
qui le rend plus simple à manipuler pour les non informaticiens, et en outre la grande
fiabilité et disponibilité du système.
2- Design pattern MVC (Modèle-Vue-

Controller)
Le MVC est une architecture et une méthode de conception qui organise l'Interface
Homme-Machine (IHM) d'une application logicielle. Il divise l'IHM qui est la couche
présentation de l’architecture 3-tiers en un modèle (modèle de données), une vue
(présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion
des évènements, synchronisation), chacun ayant un rôle précis dans l'interface.
Cette méthode a été mise au point en 1979 par Trygve Reenskaug, qui travaillait
alors sur Smalltalk dans les laboratoires de recherche Xerox PARC. L'organisation
globale d'une interface graphique est souvent délicate. L'architecture MVC ne résout
pas tous les problèmes, elle fournit souvent une première approche qui peut ensuite
être adaptée et offre aussi un cadre pour structurer une application.
77
Ce patron d'architecture impose la séparation entre les données, la présentation et
les traitements, ce qui donne trois parties fondamentales dans l'application finale :
le modèle, la vue et le contrôleur.
Figure 36 : Schéma du modèle MVC
• Le modèle : Le modèle représente le comportement de l'application,

traitements des données, interactions avec la base de données, etc. Il décrit
ou contient les données manipulées par l'application. Il assure la gestion de
ces données et garantit leur intégrité. Dans le cas typique d'une base de
données, c'est le modèle qui la contient. Le modèle offre des méthodes pour
mettre à jour ces données (insertion, suppression, changement de valeur). Il
offre aussi des méthodes pour récupérer ces données. Les résultats renvoyés
par le modèle sont dénués de toute présentation. Dans le cas de données
importantes, le modèle peut autoriser plusieurs vues partielles des données.
• La vue : Elle affiche les informations collectées à partir du modèle et
donne aux utilisateurs un moyen d’interagir avec ces informations. Elle a aussi
pour tâche de recevoir toutes les actions de l'utilisateur (clic de souris,
sélection d’une entrée, boutons, …). Ces différents évènements sont envoyés
au contrôleur. Plusieurs vues, partielles ou non, peuvent afficher des
informations d'un même modèle.
• Le contrôleur : Les interactions de l’utilisateur avec une vue sont
transformées en requêtes sur le contrôleur, qui, à son tour, peut demander
une modification des informations au modèle. Le contrôleur prend également
en charge la conversion et la mise en forme des données pour leur
présentation à l’utilisateur. Par exemple, le modèle peut enregistrer les
données en pouces, mais, conformément aux préférences de l’utilisateur, le
contrôleur peut les convertir en centimètres. Le modèle peut enregistrer des
objets dans une collection non ordonnée, mais le contrôleur peut trier les
objets avant de les transmettre à une vue pour leur affichage à l’utilisateur.
78
II. ÉTUDE ET CHOIX DU SYSTÈME
DE GESTION DE BASE DE
DONNÉES (SGBD)
Nous allons présenter dans cette partie les différents SGBD qui s’offrent à nous tels
qu’Oracle, SQL Server 2008 et MySQL.
1- ORACLE
La version actuelle est la version 12c. Oracle est disponible pour les systèmes
d’exploitation Linux, Windows, Unix, MacOs. La licence est commerciale mais
gratuite dans la version Express. Oracle n’est pas un SGBD relationnel pour les petites
bases de données. Sur de petits volumes de traitements (2 Go par exemple) et peu
d’utilisateurs (une trentaine) vous pourriez trouver des benchmark ou MySQL offre
des performances quasi comparables à Oracle. Si l’on monte à de plus importants
volumes de données (> 200 Go) et un grand nombre d’utilisateurs (>300) les écarts
entre Oracle et les autres SGBD seront très visibles.
2- SQL Server
SQL Server est un système de gestion de base de données développé par Microsoft,
disponible uniquement sur la plateforme WINDOWS. Il permet de stocker, traiter et
sécuriser les données. Sa version SQL Server 2016 propose les fonctions nécessaires
pour faire face à des besoins de performance et de haute disponibilité, garantir la
cohérence des données à l’aide des transactions et permettre la gestion des accès
concurrents.
3- MySQL
MySQL dérive directement de SQL (Structured Query Language) est un langage de
requête vers les bases de données exploitant le modèle relationnel. MySQL est un
serveur de bases de données relationnelles SQL développé dans un souci de
performances élevées en lecture, ce qui signifie qu'il est davantage orienté vers le
service de données déjà en place que vers celui de mises à jour fréquentes et
fortement sécurisées. Il est multi-thread et multi-utilisateur. C'est un logiciel libre
développé sous double licence en fonction de l'utilisation qui en est faite : dans un
produit libre ou dans un produit propriétaire. Dans ce dernier cas, la licence est
payante, sinon c'est la licence publique générale GNU (GPL) qui s'applique .
79
4- Choix du SGBD
Transaction Rapidité Gratuité Résistance Facilité Portabilité
d’administration
(OS+Cloud)
Oracle 11g
SQL
Server
2014
MySQL 5
Tableau 23 : Résumé comparatif des SGBD
Les SGBD Oracle, MYSQL conviennent tous à notre projet parce qu’ils sont
compatibles à l’environnement système de la Mu.P.I. Cependant l’objectif ici n’étant
pas de choisir le meilleur sur le marché mais le système qui répond au mieux à nos
exigences sur le projet nous avons arrêté notre choix sur MYSQL. En effet MySQL est
dérivé du SQL, il est simple d’installation et d’utilisation. Il est libre et gratuit et
disponible sur un grand nombre de platforms (Linux, MacOSX, Windows, Unix, BSD).
III. ÉTUDE ET CHOIX DE LA

TECHNIQUE DE DÉVELOPPMENT
L’architecture de développement étant choisie, nous devons définir les éléments
techniques qui permettront la mise en œuvre. Ici, serons effectués les choix
concernant le serveur web et les langages de programmation.
1- Langage de script coté server

La conception des applications Web a beaucoup évolué ces dernières années. Les
applications sont riches et exigent des mises à jour fréquentes. Les langages de
scripts côté serveur ont donc pour rôle principal d’assurer le dynamisme de ses
applications. Vu la multitude de langages existants, cette partie sera consacrée au
choix du langage le plus approprié pour la conduite de notre projet. Les langages
étant nombreux, nous allons en présenter deux parmi les plus répandus. Ce sont :
− PHP (HyperText Preprocessor) ;
− Java EE (Java Entreprise Edition).
80
a. PHP
Le langage PHP (acronyme pour PHP: Hypertext Préprocesseur), est créé en 1994 par
Rasmus Lerdorf pour son site Web. C'était à l'origine une bibliothèque logicielle dont
il se servait pour conserver une trace des visiteurs qui venaient consulter son CV. Au
fur et à mesure qu'il ajoutait de nouvelles fonctionnalités, Rasmus a transformé la
bibliothèque en une implémentation en langage C, capable de communiquer avec
des bases de données et de créer des applications dynamiques et simples pour le
Web. En 1997, deux étudiants, Andi Gutmans et Zeev Suraski, redéveloppèrent le
cœur de PHP/FI. Ce travail aboutit un an plus tard avec Zend Engine, le nouveau
cœur de PHP/FI, devenu alors PHP: Hypertext Preprocessor en version 3. Le langage
PHP est utilisé principalement en tant que langage de script côté serveur, ce qui
veut dire que c'est le serveur (la machine qui héberge la page web en question) qui
va interpréter le code PHP et générer du code (constitué généralement d'XHTML ou
d'HTML, de CSS, et parfois de JavaScript) qui pourra être interprété par un
navigateur. C'est un langage peu typé et souple et donc facile à apprendre par un
débutant mais, de ce fait, des failles de sécurité peuvent rapidement apparaître
dans les applications. Pragmatique, PHP ne s'encombre pas de théorie et a tendance
à choisir le chemin le plus direct.
b. Java EE/Java 2E
J2EE est l'acronyme de Java Entreprise Edition. Cette édition de Java est dédiée à la
réalisation d'applications pour entreprises. J2EE est basé sur J2SE (Java 2 Standard
Edition) qui contient les API de base de Java. Depuis sa version 5, J2EE est renommée
Java EE (Enterprise Edition). J2EE est une plate-forme fortement orientée serveur
pour le développement et l'exécution d'applications Web. Elle est composée de deux
parties essentielles :
• Un ensemble de spécifications pour une infrastructure dans laquelle
s'exécutent les composants écrits en Java : un tel environnement se nomme
serveur d'applications.
• Un ensemble d'APIs qui peuvent être obtenues et utilisées séparément. Pour
être utilisées, certaines nécessitent une implémentation de la part d'un
fournisseur tiers.
J2EE permet une grande flexibilité dans le choix de l'architecture de l'application en
combinant les différents composants. Ce choix dépend des besoins auxquels doit
répondre l'application mais aussi des compétences dans les différentes API de J2EE.
L'architecture d'une application se découpe idéalement en au moins trois tiers :
• La partie « cliente » : c'est la partie qui permet le dialogue avec l'utilisateur.
Elle peut être composée d'une application standalone6, d'une application web
ou d'applets.
• La partie « métier » : c'est la partie qui encapsule les traitements.
• La partie « données » : c'est la partie qui stocke les données.
81
2- Choix de la technologie de
développement
Langage Rapidité Multiplateforme Puissance Sécurité
Java EE
PHP
Tableau 24 : Résumé comparatif des technologies de développement
Afin de mener à bien le choix de notre technologie, nous effectuons une étude
comparative de ces différentes technologies.
Notre choix s’est porté sur la technologie de développement JAVA EE pour sa

rapidité, sa sécurité, sa puissance. Il est aussi multiplateforme dans le
développement d’applications.
IV. SERVEUR D’APPLICATION

Un serveur d'applications est un logiciel d'infrastructure offrant un contexte
d'exécution pour des composants applicatifs. Le terme est apparu dans le domaine
des applications web. Dans un sens strict les composants hébergés par le serveur
d'applications ne sont pas de simples procédures ou scripts mais de réels composants
logiciels conformes à un modèle de composants (EJB, COM, Fractal, etc.). Les clients
des serveurs d'application sont des programmes autonomes (standalone application),
des applets ou d'autres composants. La structuration en couches des différents
composants mis à disposition par le serveur d'application permet une prise en compte
des besoins métier, des intéractions avec les utilisateurs, des connexions avec les
bases de données, etc. Dans un sens plus large, un serveur d'application peut être
une machine servant à héberger des applications soit pour permettre leur exécution
depuis un poste client (mode client-serveur de données, généralement partage de
fichiers et politiques de gestion des accès) ou pour déporter l'affichage sur le poste
client (mode client-serveur d'affichage). Il existe aujourd’hui plusieurs serveurs
d’applications, nous citerons les plus utilisés et nous ferons par la suite une
comparaison afin de justifier le choix pour notre serveur d’application.
82
1- JBoss
JBoss Application Server est un serveur d'applications J2EE Libre entièrement écrit
en Java, publié sous licence GNU LGPL. Parce que le logiciel est écrit en Java, JBoss
Application Server peut être utilisé sur tout système d'exploitation fournissant une
machine virtuelle Java (JVM).
JBoss Application Server implémente entièrement l'ensemble des services J2EE. Il
embarque :
• Tomcat : serveur web Tomcat pour exécuter les parties servlets et JSP des
applications déployées sur le serveur.
• JBoss Portal : framework de portail.
• JBoss Seam : framework web.
• Hibernate : Framework de persistance.
• JBPM : moteur de workflow.
• Rules : système de gestion de règles métier.
2- Apache Tomcat
Apache Tomcat est un conteneur libre de servlets et JSP Java EE. Issu du projet
Jakarta, c'est un projet principal de l’Apache Software Foundation. Il implémente
les spécifications des servlets et des JSP du Java Community Process, est
paramétrable par des fichiers XML et de propriétés, et inclut des outils pour la
configuration et la gestion. Il comporte également un serveur HTTP. Tomcat ne
constitue qu'un conteneur web, et non un serveur Web à part entière : il gère
spécifiquement les servlets et les JSP (un compilateur Jasper compilant les pages
JSP pour en faire des servlets). Il peut être également parfois désigné comme moteur
de servlet, ou plus abusivement comme un serveur Web. Tomcat est en réalité
souvent employé en combinaison avec un serveur Web Apache ou d'autres serveurs
Web (JBoss, IIS, WebSphere, etc). Tomcat a été écrit en langage Java. Il peut donc
s'exécuter via la machine virtuelle Java sur n'importe quel système d'exploitation la
supportant. Les membres de la fondation Apache et des volontaires indépendants
développent et maintiennent Tomcat. Les utilisateurs ont accès au code source et
aux binaires sous la Apache Software License. L'architecture du logiciel se compose
ainsi :
• Un serveur soit Tomcat en cours d'exécution
o Des services intermédiaires collectant différents canaux de
transmissions vers un traitement.
▪ Un moteur qui pour chaque service traite les requêtes des
collecteurs et renvoie les réponses.
o Des hôtes qui relient une adresse réseau avec le serveur
o Des connecteurs qui interprètent un canal et protocole de
communication réseau à disposition des clients. Le connecteur HTTP
est le plus typique.
83
o Des contextes qui sont les applications web.
Le contexte est le lieu privilégié pour situer un service informatique que l'on veut
rendre sur un réseau. Les autres modules sont mis en œuvre par le logiciel Tomcat
lui-même. Par ailleurs, Tomcat est à sa version 8.5.
Figure 37 : Architecture conteneur web java
3- Choix du server d’application

JBoss Serveur Tomcat
Prix Gratuit Gratuit
Fonctionnalité intégré Bon Bon
Complexité/ puissance Bon Bon
Utilisation Bon Bon
Hébergement/ portabilité Moyen Elevé
Tableau 25 : Résumé comparatif des serveurs d'application
84
V. PRÉSENTATION ET CHOIX DES
FRAMEWORK
Les Framework se présentent sous diverses formes, qui peuvent inclure :
− Un ensemble de classes ;
− Un cadre de conception ;
− Des recommandations sur la mise en œuvre et des exemples d'utilisation ;
− Des normes de développement ;
− Des outils facilitant la mise en œuvre.
Leur objectif est de faciliter la mise en œuvre des fonctionnalités de son domaine
d'activité. Il doit permettre au développeur de se concentrer sur les tâches
spécifiques à l'application à développer plutôt qu'à des tâches techniques.
Nous allons nous concentrer ici sur les Framework de présentations.
Un compassant d’interface graphique (aussi appelé widget en anglais ou encore
control) est un élément de base d’une interface graphique avec lequel un utilisateur
peut interagir (par exemple une fenêtre, une zone de texte). Ces composants sont
généralement regroupés dans des boites à outils graphiques (appelées Toolkit en
anglais). Une fois assemblés par un programmeur, ces composants forme une
interface graphique complète. Les Framework de présentation les plus utilisés sont :
− Wicket ;
− GWT (Google Web Toolkit) ;
− Boostrap.
1- Wicket
Wicket est un Framework à base de composants, à l’inverse des Framework M-V-C
(Modèle-Vue-Contrôleur) traditionnels à base d’actions, comme apache Struts ou
Spring MVC par exemple. Apache Wicket est un Framework léger d'application web
basée sur les composants pour le langage de programmation Java. Wicket est modelé
après des cadres d'interface graphique stateful. Il comporte des arborescences de
composants qui utilisent des délégués écouteurs pour réagir aux requêtes HTTP
contre les liens et les formulaires. Avec XHTML pour les modèles, il distingue la
logique de présentation et d'affaires et permet de modifier les modèles avec les
outils de conception WYSIWYG conventionnels. Dans le cadre, chaque composante
est soutenue par son propre modèle qui représente l'état des composants. Wicket
pourrait être le meilleur cadre pour utiliser les ressources des développeurs.
85
2- GWT (Google Web Toolkit)
L’outil de Google est dédié à la présentation. Il permet de coder 5 fois plus vite la
couche graphique Web de son application. GWT repose sur un modèle en composant.
Par exemple, il dispose d’objet champ texte, tableau…… Chacun de ces composants
supporte les CSS et est donc potentiellement skinnable.
GWT est un Framework, extensible et open source, de développement permettant
de créer en Java des pages HTML/JavaScript riches. Il permet :
− Le debug avec les outils java classiques ;
− La compilation en JAVASCRIPT ;
− L'optimisation pour les navigateurs.
Les objectifs de GWT sont :
− Ergonomie et interface riche (retour client lourd mais sans les contraintes de
déploiement) ;
− Cible multi navigateur (affranchissement des contraintes du JAVASCRIPT) ;
− Développement Full Java (utilisation de Java comme langage de
développement) le code généré par GWT supporte les principaux navigateurs ;
− Dialogue client/serveur asynchrone (AJAX).
3- Bootstrap
Bootstrap qui est un Framework d’interface utile à la création d’application web. Il
représente une collection d’outils qui contient des codes HTML et CSS, des
formulaires, boutons, outils de navigation et autres éléments interactifs, ainsi que
des extensions JavaScript en option. Bootstrap fournit une feuille de style CSS qui
contient des définitions de base pour tous les composants HTML, ce qui permet de
disposer d'une apparence uniforme pour les textes, tableaux et les éléments de
formulaires. Le Framework fournit également nombres d'éléments graphiques au
format standardisé : boutons, libellés, icônes, miniatures, barres de progression.
4- Comparaison des Framework

d’interface et choix
➢ Le Framework Wicket présente de nombreux avantages comme l’utilisation des
pages XHTML comme technologie de présentation et la séparation de l’HTML et
le code java. Il permet aussi de séparer la partie cliente et la partie serveur.
Néanmoins ses inconvénients sont non négligeables. En effet Wicket stocke
beaucoup d’informations en session et il est donc trop lourd pour gérer plusieurs
centaines d’utilisateurs simultanés. A l’usage, on se rend compte que
l’intégration manuelle avec le JavaScript n’est pas évidente.
86
➢ Quant au Google Web Toolkit, il possède deux avantages notables à savoir que,
côté intégration à un modèle de page, il n’y aurait aucun souci. Il suffit de partir
du HTML et d’appliquer les styles au composants GWT et le fait qu’il offre des
composants tels qu’un agenda facile à intégrer. Cependant non seulement il
manque de documentation mais il n’y a que des composants graphiques « simple».
Si l’on veut utiliser des composants plus évolués, il faut soit les coder ou bien se
tourner vers des librairies de widgets GWT open source « non google ».
➢ Bootstrap lui peut être très rapidement prise en main ce qui permet un gain de
temps considérable. Il est compatible avec la plupart des navigateurs utilisés et
possède une communauté de développeurs très importante.
Enfin, Bootstrap utilise du LESS Scripts JavaScript pré-intégrés personnalisable et
modulable ce qui permet une réutilisation. Ce qu’on peut lui reprocher est sa
lourdeur comparée aux autres Framework CSS.
Le choix de notre Framework d’interface s’est porté sur BOOSTRAP car
il intègre plus d’éléments (widgets) javascript et de fonctions permettant de gagner
beaucoup de temps lors de l’intégration ou prototyping rapide. Du côté de la rapidité
de mise en œuvre, et de créations d’applications/ERPs basés sur bootstrap, le gain
de temps est énorme, toutes les fonctions nécessaires étant présentes et
correctement imbricables, il suffit d’aligner des balises pour créer son interface le
plus simplement du monde, dans le style Bootstrap. Bootstrap permet donc de créer
plus facilement des applications web ou ERPs au design clair et agréable.
En outre un grand avantage qu’offre Boostrap aujourd’hui est qu’il soit
« responsive ». Donc une interface graphique composé de widget Boostrap s’adapte
automatiquement à tout sorte d’écran (smartPhone,tablette…).
VI. OUTILS DE DEVELOPPEMENT

1- Présentation des IDE
IDE (Integrated Development Environment) est un environnement de développement
intégré et une application logicielle qui fournit des installations complètes pour les
programmeurs informatiques pour le développement de logiciels. Un IDE se compose
normalement d'un éditeur de code source, construire des outils d'automatisation et
un débogueur. La plupart des IDE modernes disposent d'un code intelligent
d’achèvement.
Dans l’environnement java il existe plusieurs IDE mais les plus utilisés par les
développeurs sont Eclipse et Netbeans.
87
2- ECLISPE Néon
Eclipse est un IDE (Integrated Development Environment) open source à l'origine
développé par IBM pour ses futurs outils de développement et offert à la
communauté. Le but est de fournir un outil modulaire capable non seulement de
faire du développement en Java mais aussi dans d'autres langages et d'autres
activités. Cette polyvalence est liée au développement de modules (plug-in) réalisés
par la communauté ou des entités commerciales. Bien que développé en Java, les
performances à l'exécution d'Eclipse sont très bonnes car il n'utilise pas Swing pour
l'interface homme-machine mais un toolkit particulier nommé SWT associé à la
bibliothèque JFace. SWT (Standard Widget Toolkit) est développé en Java par IBM
en utilisant au maximum les composants natifs fournis par le système d'exploitation
sous-jacent. JFace utilise SWT et propose une API pour faciliter le développement
d'interfaces graphiques.
Eclipse ne peut donc fonctionner que sur les plateformes pour lesquelles SWT a été
porté. SWT et JFace sont utilisés par Eclipse pour développer le plan de travail
(Workbench) qui organise la structure de la plate-forme et les interactions entre les
outils et l'utilisateur. Cette structure repose sur trois concepts : la perspective, la
vue et l'éditeur. La perspective regroupe des vues et des éditeurs pour offrir une
vision particulière des développements. En standard, Eclipse propose huit
perspectives. Les vues permettent de visualiser et de sélectionner des éléments. Les
éditeurs permettent de visualiser et de modifier le contenu d'un élément de l'espace
de travail.
3- NETBEANS
Netbeans est un environnement de développement open source écrit en Java. Le
produit est composé d'une partie centrale à laquelle il est possible d'ajouter des
modules. Netbeans est un IDE open source racheté et développé par Sun
Microsystems. Netbeans propose des fonctionnalités permettant le développement
d'applications standalone (AWT/Swing), web (Servlets, JSP, Struts, JSF), mobile
(J2ME) ou d'entreprise (J2EE/JEE). Il fonctionne sous Windows, Linux, Mac OS X et
Solaris. Netbeans est modulaire et propose plusieurs plugins officiels :
• Mobility Pack : Pour le développement d'applications mobiles avec une
conception WYSIWYG. Il existe une version pour le développement avec le
profile CLDC/MIDP et une autre avec le profile CDC.
• Visual Web Pack : Pour le développement d'applications web avec une
conception WYSIWYG.
• Enterprise Pack : Pour le développement de service web et de composants
pour une architecture de type SOA avec une conception WYSIWYG.
• Profiler : Pour profiler une application.
• C/C++ Pack : Pour le développement d'applications en C/C++.
88
Il existe aussi de nombreux plugins développés par des tiers. Quelques
fonctionnalités de Netbeans sont particulièrement intéressantes :
− Le développement WYSIWYG d'applications reposant sur Swing (projet
Matisse) qui propose un positionnement aisé des composants ;
− Le plug-in Mobility pack qui facilite le développement des midlets en gérant
leurs enchaînements graphiquement ;
− Le support des dernières technologies Java ;
− Le développement WYSIWYG d'applications web avec les JSF (plug-in Visual
web Pack).
4- Comparaison des IDE et choix
IDE Portabilité Faible Génération Grande Richesse

utilisation de code communauté des plugins
des des
ressources utilisateurs
Netbeans
Eclipse
Néon
Tableau 26 : Résumé comparatif des IDE
Eclipse Néon est l’IDE retenu pour notre projet parce qu’il intègre toutes les
fonctionnalités pour la programmation web en l’occurrence Java EE.
89
CHAPITRE VI : RÉALISATION
TECHNIQUE
I. ARCHITECTURE DU SYSTÈME
1- Architecture fonctionnelle
Notre solution est un portail web qui permettra d’automatiser en partie la gestion
administrative de la Mu.P.I. Les différents groupes d’utilisateurs de notre solution
sont :
− Le personnel administratif de la Mu.P.I ;
− Les membres ordinaires de la Mu.P.I ;
− Les partenaires de la Mu.P.I.
A l’instar de ces différents utilisateurs notre solution offre les fonctionnalités
regroupées comme suit :
− Suivi des tâches administratives : activités, assemblées générales et réunions,
prestation ;
− Gestion de la collaboration avec les partenaires : opérations effectuées chez
un partenaire, projet ;
− Communication entre les différents utilisateurs : messaging et mailing ;
− Administration : authentification et gestion des droits utilisateurs.
2- Diagramme de déploiement
Les diagrammes de déploiement montrent la disposition physique des matériels qui
composent le système et la répartition des composants sur ces matériels. Les
ressources matérielles sont représentées sous forme de nœuds. Les nœuds sont
connectés entre eux, à l'aide d'un support de communication. La nature des lignes
de communication et leurs caractéristiques peuvent être précisées. Dans notre cas,
nous présenterons les interactions entre :
− Le serveur de base de données qui héberge la base de données ;
− Le serveur d’applications : il comprend le serveur de Web Services Apache
Tomcat, l’application J2EE et les entités provenant de la base de données
− Les postes des utilisateurs (administrateur et utilisateur simple).
Il en ressort le diagramme de déploiement suivant :
90
Figure 38 : Diagramme de déploiement
91
II. PRÉSENTATION DE LA SOLUTION
1-Interface d’accueil de l’application
Figure 39 : Interface d’accueil de l’application
92
2-Interface de connexion
Figure 40 : Interface de connexion
93
CHAPITRE VII : ÉVALUATION
FINACIÈRE
L’évaluation financière de ce projet ne prendra en compte que la phase de

production. En effet Cette partie nous permet de faire le bilan en matière de coût
des différents choix effectués. Nous avons classé les besoins comme suit :
− Besoins humains ;
− Besoins matériels ;
− Besoins logiciels.
I. ÉVALUATION JOUR-HOMME
Jour-Homme est l’unité de mesure correspondant au travail d’une personne pendant
une journée. Par exemple, un projet qui demande dix jours-hommes nécessite
théoriquement le travail soit d’un homme pendant dix jours, ou de dix hommes
pendant un jour, ou encore de deux hommes pendant cinq (05) jours.
II. ÉVALUATION DE LA CHARGE

RÉELLE
Pour la conception et la réalisation de notre projet, la charge travail était estimée
à environ 95 jour-homme. Ce qui revient à le réaliser sur une période de 3 mois et 3
jours pour quatre (04) techniciens.
94
Ressources Nombre Fonction Nombre Prix par jour Prix total
humaines jours (FCFA) (FCFA)
Analyste et 2 Modélisation 45 10000 450.000

Développeur métier, analyse
Puis Analyse,
Conception et
Implémentation
Développeur 2 Analyse, 50 10000 500.000

BD et Testeur Conception et
Implémentation
puis élaboration
des Tests
Total 950 000 F

CFA
Tableau 27 : Cours de la charge JOUR-HOMME
III. ÉVALUATION DES MATERIELS ET

LOGICIEL
Dans cette partie nous évaluerons les ressources matériels et logiciels que nous allons
utiliser pour réaliser notre projet.
Matériels et logiciels Nombre Fonction Prix(FCFA) Commentaires
Eclipse Néon 2 IDE 0 Gratuit

Ordinateurs portables 4 Equipement des 0 Disponible
(HP et Toshiba) élèves techniciens
supérieurs
Astah Community 1 Logiciel de 0 Disponible
modélisation UML
Phpmyadmin 1 SGBD 0 Disponible
Apache Tomcat 1 Conteneur web 0 Disponible
Windows 8.1 2 Système 0 Disponible
d’exploitation
Total 0
Tableau 28 : Récapitulatif des cours matériel et logiciels du projet
95
Le tableau précédent montre en effet le fait que nous disposons déjà de toutes les
ressources matérielles et logicielles nécessaires pour la réalisation des différentes
tâches.
IV. CONSTRUCTION DU PLANNING

D’EXÉCUTION
Les différentes étapes de la conception à la réalisation sont présentées dans cette
section. La charge de travail nous a permis de déduire les délais d’exécution suivant
PHASES DUREE D’EXECUTION
1 Définition des besoins des utilisateurs 5 jours

2 Modélisation 20 jours
3 Planification de l’architecture, du 10 jours
déploiement et de la sécurité
4 Sélection et installation des outils 3 jours
5 Conception et Développement de 30 jours

l’application web (projet)
6 Test et modification de l’application web 15 jours
7 Déploiement 5 jours
8 Formation des utilisateurs 7jours
Tableau 29 : Plan d'exécution
96
CONCLUSION
Pour automatiser son fonctionnement, la Mu.P.I. nous a soumis comme thème
d’étude « CONCEPTION ET MISE EN ŒUVRE D’UNE APPLICATION WEB POUR LA
GESTION DE LA MUTUELLE DU PERSONNEL DE L’INP-HB (Mu.P.I) ». Dans notre
méthode d’étude nous avons d’abord étudié le fonctionnement de la Mu.P.I avec les
moyens existants pour en dégager les forces et les faiblesses. Ensuite, les résultats
de cette étude, couplés aux exigences des utilisateurs nous ont permis d’aborder la
conception du système à partir du Processus Unifié, de ses variantes et de son
langage de modélisation UML. Enfin, se basant sur des études comparatives, nous
avons fait plusieurs choix techniques quant aux architectures, technologies et outils
de développement à utiliser pour la réalisation.
A ce jour, malgré quelques difficultés, l’implémentation de la solution avance bien.

La première itération sera livrée à la Mu.P.I dans les jours à venir. Elle servira à
recenser les différents membres de ladite mutuelle, à leur permettre de faire la
description de leurs compétences et à les mettre en ligne de sorte à être accessible
au grand public.
Par ailleurs, conscient du fait que ce système ne serait d’aucun apport sans la
participation effective de tout le personnel de l’INP-HB, nous allons procéder à une
sensibilisation sur l’intérêt de cette application web et organiser des séances de
formations pour la bonne gestion de celle-ci.
En ce qui nous concerne, ce travail fût très enrichissant pour nous. Il nous a permis
d’une part d’appliquer nos connaissances théoriques acquises pendant notre
formation à la pratique et, d’autre part, de nous familiariser à la gestion de projets.
Nous avons été honorés de travailler sur ce projet.
97
BIBLIOGRAPHIE
LIVRES
[1] Philippe KRUCHTEN, The rational Unified Process An introduction, Addison-
WESLEY 2000.
[2] Laurent Audibert, UML 2.0, Paris 13.
[3] Jérémie Guiochet ,UP NTIE , Master 1 ,2009,
[4] Joseph Gabay et David Gabay,UML 2 Analyse et conception,Dunod 2008.
[5] Gautier Picard, Conduite de projet Méthode d’analyse et de conception
Processus Unifié,Octobre 2009
[6] Yves Wautelet et Laurent Louvigny et Manuel Kol, Le Unified Process comme
methodologie de gestion de projet informatique, IAG- ISYS (Unité de Systèmes
d’Information).
[7] Philippe Kruchten, Introduction au Rational Unified Process, Editions Eyrolles
1999.
[8] Dominique NANCI, Bernard ESPINASSE, Bernard COHE, Ingénierie des systèmes
d’information : Merise ; deuxième génération, 4édition, Paris : Vuibert, 2001, 538
pages.
MEMOIRE DE FIN DE CYCLE

[9] Adjobia K. Franck Yannick et Beguhe Kama Henry Joel, conception et mise en
œuvre d’une application web par composants graphiques reutilisables pour la
gestion de la mutuelle du personnel de l’inp-hb (mu.p.i), projet interne ingénieur
informatique 3ème année, INP-HB, ESI, 2016 -2017.
VII
WEBOGRAPHIE
[1] http://www.memoireonline.com/07/08/1287/m_mise-en-place-d-une-plate
forme-decartographie-dynamique5.html Mise en place d'une plateforme de
cartographie dynamique par Issa Baldé, Ecole Supérieure Polytechnique de Dakar -
Ingénieur de conception en Génie Informatique 2008, consulté le 10 Décembre
2017.
[2] http://docplayer.fr/1027770-Processus-de-developpement
logiciel.html,Processus de Développement Logiciel, CoursM14,
PierreGérard,Université de Paris 13 IUT Villetaneuse Formation Continue, Licence
Pro SIL-2007/2008, consulté le 13 Décembre 2017.
[3] http://nocremetz.free.fr/polytech/methodologies/websites/methodo/www.dsi
cnrs.fr/bureau_qualite/developpement-web/methodologie/veille
methodologie.html, Liens utiles - Etat de l'art des méthodologies, consulté le 13
Décembre 2017.
[4] http://michel-divine.developpez.com/#page_ParlezVousMerise, Michel Diviné «
Parlezvous Merise ? », consulté le 18 Décembre 2017.
[5] http://gardeux
vincent.eu/Documents/ProjetJEE/LMNTF_Hibernate_JSF/hibernate.html consulté
le 8 Janvier 2018.
[6] https://www.franceculture.fr/economie/des-librairies-de-plus-en-plus-fragiles,
consulté le 14 Janvier 2018.
[7] https://general.developpez.com/edi/, meilleurs environnement de
développement, consulté le 20 Janvier 2O18.
[8] http://www.memoireonline.com/07/10/3700/m_Conception-et-realisation-
duneapplication-web-pour-la-gestion-des-stocks-cas-detude-magasin8.html
Conception et réalisation d'une application web pour la gestion des stocks cas
d'étude magasin de la faculté des sciences exactes de l'université de Bejaia-par
Laaziz LAHLOU, Université de Bejaia Licence Académique en Mathématique et
Informatique Option Informatique Générale 2010, consulté le 5 Février 2018.
[9] https://blog.axopen.com/2014/06/java-vs-php-creation-dune-application-web-
site-web-en-2014/ JAVA vs PHP pour la création d’une application web ou site web
en 2014, consulté le 7 Février 2018.
VIII
TABLE DES MATIÈRES
DÉDICACE ......................................................................................... I
REMERCIEMENTS ................................................................................ II
SOMMAIRE ...................................................................................... III
LISTE DES FIGURES ............................................................................ IV
LISTE DES TABLEAUX ........................................................................... V
AVANT-PROPOS ................................................................................ VI
INTRODUCTION ................................................................................. 1
PARTIE 1 : ÉTUDE PRÉALABLE ................................................................ 2
CHAPITRE I : PRÉSENTATION DE LA STRUCTURE D’ACCUEIL ............................. 3
I. PRÉSENTATION .......................................................................... 3
II. OBJET DE LA MU.P.I .................................................................... 3
III. ORGANIGRAMME DE LA Mu.P.I ...................................................... 3
CHAPITRE II : PRÉSENTATION DU PROJET................................................... 5
I. PRÉSENTATION DU THÈME ............................................................. 5
II. PRÉSENTATION DU CAHIER DES CHARGES ........................................... 5
1- Présentation du contexte ........................................................... 5
2- Objectifs principaux de l’application ............................................. 7
III. ÉTUDE DE L’EXISTANT ............................................................... 8
1- Étude de l’existant................................................................... 8
2- Objectifs............................................................................... 8
PARTIE 2 : ÉTUDE CONCEPTUELLE ........................................................... 9
CHAPITRE III : MÉTHODE D’ANALYSE ET DE CONCEPTION .............................. 10
I. PRÉSENTATION DU PU/UML .......................................................... 11
1- Etude de l’existant.................................................................. 11
2- Les 4 + 1 vues du Processus unifié ................................................ 13
3- La démarche du Processus unifié ................................................. 14
4- Déclinaison du Processus unifié ................................................... 17
II. PRÉSENTATION DE MERISE ............................................................ 18
1- Le cycle de vie ou la démarche ................................................... 18
2- Le cycle d’abstraction ou le raisonnement ...................................... 18
III. CHOIX DE LA MÉTHODE ............................................................. 20
IX
1- Comparaison PU et MERISE ........................................................ 20
2- Choix de la méthode ................................................................ 21
CHAPITRE IV : CONCEPTION DU SYSTÈME .................................................. 25
I. DÉFINITION ET ANALYSE DES BESOINS .............................................. 25
1- Identification des acteurs .......................................................... 25
2- Identification des messages ....................................................... 26
3- Identification des cas utilisation .................................................. 28
II. DÉVELOPPEMENT DU MODÈLE STATIQUE : DIAGRAMME DE CLASSE ............. 64
PARTIE 3 : ÉTUDE TECHNIQUE ET RÉALISATION........................................... 69
CHAPITRE V : CHOIX DES TECHNIQUES DE MISE EN OEUVRE ............................ 70
I. ARCHITECTURE DE LA SOLUTION .................................................... 70
1- Présentation des architectures ................................................... 70
2- Design pattern MVC (Modèle-Vue-Controller) ................................... 77
II. ÉTUDE ET CHOIX DU SYSTÈME DE GESTION DE BASE DE DONNÉES (SGBD) ..... 79
1- ORACLE ............................................................................... 79
2- SQL Server ............................................................................ 79
3- MySQL ................................................................................. 79
4- Choix du SGBD ....................................................................... 80
III. ÉTUDE ET CHOIX DE LA TECHNIQUE DE DÉVELOPPMENT....................... 80
1- Langage de script coté server ..................................................... 80
2- Choix de la technologie de développement ..................................... 82
IV. SERVEUR D’APPLICATION ........................................................... 82
1- JBoss .................................................................................. 83
2- Apache Tomcat ...................................................................... 83
3- Choix du server d’application ..................................................... 84
V. PRÉSENTATION ET CHOIX DES FRAMEWORK ........................................ 85
1- Wicket ................................................................................ 85
2- GWT (Google Web Toolkit) ........................................................ 86
3- Bootstrap ............................................................................. 86
4- Comparaison des Framework d’interface et choix ............................. 86
VI. OUTILS DE DEVELOPPEMENT ....................................................... 87
1- Présentation des IDE ................................................................ 87
2- ECLISPE Néon ........................................................................ 88
3- NETBEANS ............................................................................ 88
4- Comparaison des IDE et choix ..................................................... 89
CHAPITRE VI : RÉALISATION TECHNIQUE ............................................... 90
X
I. ARCHITECTURE DU SYSTÈME ......................................................... 90
1- Architecture fonctionnelle ......................................................... 90
2- Diagramme de déploiement ....................................................... 90
II. PRÉSENTATION DE LA SOLUTION .................................................... 92
1- Interface d’accueil de l’application .............................................. 92
2- Interface de connexion ............................................................. 93
CHAPITRE VII : ÉVALUATION FINACIÈRE .................................................... 94
I. ÉVALUATION JOUR-HOMME ........................................................... 94
II. ÉVALUATION DE LA CHARGE RÉELLE ................................................ 94
III. ÉVALUATION DES MATERIELS ET LOGICIEL ....................................... 95
IV. CONSTRUCTION DU PLANNING D’EXÉCUTION ................................... 96
CONCLUSION ................................................................................... 97
BIBLIOGRAPHIE ............................................................................... VII
WEBOGRAPHIE ................................................................................ VIII
TABLE DES MATIÈRES ......................................................................... IX
XI

Redaction

Transféré par

Informations du document

Description :

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Redaction

Titre original :

Transféré par

Description :

Droits d'auteur :

RÉPUBLIQUE DE COTE D’IVOIRE

UNION – DISCIPLINE – TRAVAIL

RAPPORT DE PROJET INTERNE

TS Informatique 3 2017 – 2018

En effet, le rapport suivant a été réalisé grâce au soutien constant et à

Nous adressons également nos remerciements à toute l'équipe pédagogique de

De même nous tenons vivement à remercier les membres du jury pour

Pour s’assurer un soutien social, renforcer la cohésion, le personnel s’est organisé,

Le sujet présenté ci-dessus éveille en nous nombre de questionnements utiles pour

La réponse à cette problématique devrait nous amener à réussir un examen abouti

II. OBJET DE LA MU.P.I

III. ORGANIGRAMME DE LA Mu.P.I

1ER VICE-PRESIDENT 2EME VICE-PRESIDENT

Figure 1 : Organigramme de la MUPI

II. PRÉSENTATION DU CAHIER DES

2- Objectifs principaux de l’application

Vue logique Vue d’implémentation

Vue des cas d’utilisation

Vue des processus Vue de déploiement

Figure 2 : Modèle représentant les 4+1 vues de Kruchten

La Processus unifié se réalise aussi au travers d’activités reparties dans les

• La modélisation métier : elle aide à la compréhension de la structure et de

Comme précédemment signalé, le processus unifié s’appuie sur un cycle de vie

Figure 4 : Cycle de vie de PU

1- Le cycle de vie ou la démarche

III. CHOIX DE LA MÉTHODE

Nom de Modélisation Modélisation Gestion Gestion du Modélisation Privilèges

Tableau 1 : Comparaison MERISE-UML

➢ Les activités du processus12

I. DÉFINITION ET ANALYSE DES

1- Identification des acteurs

a. Diagramme de contexte statique

Figure 6 : Diagramme de contexte statique

Tableau 2 : Liste des messages entre le système et les acteurs externes

3- Identification des cas utilisation

Créer compte Utilisateur, Administrateur

Publier message Utilisateur

Consulter message Utilisateur

Consulter opération Utilisateur

Enregistrer opération Partenaire

Enregistrer compétence Membre

Modifier compétence Membre

Consulter compétence Membre

Consulter partenaire Membre

Suivi du fonctionnement Membre administratif

Consulter les statistiques Président

Enregistrer une action Secrétaire Général

Modifier une action Secrétaire Général

Supprimer une action Secrétaire Général

Modifier une transaction Membre du Comité de Surveillance et de Contrôle

Supprimer une transaction Membre du Comité de Surveillance et de Contrôle

Enregistrer une transaction Trésorier

Attribuer droit Administrateur

Supprimer utilisateur Administrateur

Tableau 3 : Les cas d'utilisation

a. Le diagramme des cas d’utilisation

Post conditions Action enregistrée plus disponibles

Tableau 4 : Description textuelle de cas d’utilisation "Attribuer droit"

Tableau 5 : Description textuelle du cas d’utilisation "authentification"

Figure 9: Diagramme de séquences du cas d'utilisation "Authentification"

Nom Consulter message

Post conditions Message disponible en consultation