Voir Ses Collègues Et Être Vu Soi-Même Est Essentiel Pour Un Travail D'équipe Constructif Et Efficace

I
EPIGRAPHE
« Voir ses collègues et être vu soi-même est essentiel pour un travail d’équipe
constructif et efficace »
Michel ASSINK
II
DEDICACE
A ma très chère famille MBUYI.
KATUMBA KALABELA Patient

III
REMERCIEMENTS
Ce travail scientifique est un gain d’un long moment (temps) et de l’écoulement de
trois années d’études supérieure et universitaire que nous avons passées à l’Université Méthodiste
de Kamina (U.M.K), dans la faculté de sciences informatiques.
Sur ce, nous ne sommes pas ingrat de rendre grâce à notre créateur, pour le souffle
de vie qu’il continue à mettre dans nous, louange et adoration à lui pour son amour immesurable,
celui qui a mis l’accent à notre existence, nous voici aujourd’hui arrivé à la fin de notre premier
cycle, qu’il soit loué à jamais.
A l’Église Méthodiste Unie, d’avoir mis à la disposition de l’humanité l’Université

Méthodiste de Kamina UMK en sigle, qui a fait de nous ce que nous sommes aujourd’hui.
A Monsieur l’Assistant Valery KABONGO MPANGA Claude directeur de notre

travail, Qu’il veuille trouver à travers ces lignes un hommage pour son dévouement et sa
disponibilité, Car quoique surchargé par ses préoccupation mais a disposé son temps pour
s’intéresser à la correction de notre travail.
A toutes nos très chères autorités Académiques et Administratives plus

particulièrement au Recteur Dr KANDOLO KASOLWA de l’Université Méthodiste de Kamina,
au Docteur KILUME KINENKIDA le Secrétaire Général Académique, le Secrétaire Général
Administratif Madame Maitre Odette KYAKUTALA, Au doyen de la faculté Mr Abbé JEAN-
JACQUES MWANZA MWIKEU.
A mes parents MBUYI NGOY Gérard et KAPINGA MUKADI Justine pour tous
les sacrifices, soutiens, encouragements et conseils qu’ils ont fait durant tout mon parcourt de trois
ans.
A mon Pasteur Jean MUTOMBO pour son assistance spirituelle.
A mon Serviteur Erick BUKASA pour son assistance financière, morale et

spirituelle.
IV
A mes Assistants de la faculté, Ir GAYLAS MULENDA, Ir Trésor MWAMBA

TWITE.
A ma famille : MWADI Florance, MBELU Eulalie, MIDIKI Mireille, MUZEMBA

Peter, Dan MWAMBA, KAMWANYA Nadeige, MWADI Abigaël, KAPINGA Déborah, NGOY
Nathan, MUTOMJI Dorcas et KASEKA Angel ; pour leurs encouragements et prières.
A la famille KITENGE MUKAYA pour leurs assistances et encouragements.
A mes très cher(es) amis et amies : Chadrack MBAYO, Ornelia TSHIBINGU,

Aurelia TSHIBINGU, Aaron KAFUKA, Emmanuel KONT, Sarah TSHAMA, Remy BANZA,
Carmel KABAMBA, Sédard, Chrispain, Valentin, Prisca, Esther KABENGELE, Patrick YUMA,
Emmanuel TSHIMANGA, Casteral, Louis MPINDA, Hilde MUKANYA, Bornic KALEND,
KAIMA Hamed, Doris MBUYU, Gloire MWAMBAYI.
A mes camarades : JOJO MIKOMBE, Ali, Olivier MUTAMBA, Elie KABAMBA,

Berger NDALA, Darlene TSHAMU, Chadrack MUKAKU, Patricia KABUYA, Hyppolite
MIKOMBE, Elise NZANZA pour une bonne collaboration.
V
Figure 1: Organigramme du Bureau Episcopal ............................................................................ 23

Figure 2: Diagramme de cas d'utilisation métier .......................................................................... 26
Figure 3: Diagramme d'activités ................................................................................................... 28
Figure 4: Diagramme de cas d'utilisation ..................................................................................... 31
Figure 5: Diagramme de séquence système planifier réunion ...................................................... 33
Figure 6: Diagramme de séquence système Gérer réunions ......................................................... 34
Figure 7: Diagramme de séquence système Ajouter participant .................................................. 35
Figure 8: Diagramme de séquence système Gérer Compte .......................................................... 36
Figure 9: Diagramme de séquence système Créer compte ........................................................... 37
Figure 10: Diagramme de séquence système Authentification..................................................... 38
Figure 11: Diagramme de séquence système Chatter ................................................................... 39
Figure 12: Diagramme de séquence système Supprimer participant ............................................ 40
Figure 13: Diagramme de classes du domaine ............................................................................. 42
Figure 14: Diagramme de séquence conception Planifier réunion ............................................... 45
Figure 15: Diagramme de séquence conception Gérer Réunion .................................................. 45
Figure 16: Diagramme de séquence conception Ajouter Participant............................................ 46
Figure 17: Diagramme de séquence conception Gérer Réunion .................................................. 46
Figure 18: Diagramme de séquence conception Créer Compte.................................................... 47
Figure 19: Diagramme de séquence conception Authentification ................................................ 47
Figure 20: Diagramme de séquence conception chatter ............................................................... 48
Figure 21: Diagramme de séquence conception Supprimer Participant ....................................... 49
Figure 22: Diagramme de classes participantes Planifier réunion ................................................ 51
Figure 23: Diagramme de classes participantes Gérer Réunion ................................................... 51
Figure 24: Diagramme de classes participantes Ajouter Participant ............................................ 52
Figure 25: Diagramme de classes participantes Gérer Compte .................................................... 52
Figure 26: Diagramme de classes participantes Créer Compte .................................................... 53
Figure 27: Diagramme de classes participantes Authentification................................................. 53
Figure 28: Diagramme de classes participantes Chatter ............................................................... 54
Figure 29: Diagramme de classes participantes Supprimer Participant........................................ 54
Figure 30: Diagramme de classes conception ............................................................................... 55
Figure 31: Diagramme de deploiement......................................................................................... 58
VI
SIGLES ET ABREVIATIONS
UMC :
UMK : Université Méthodiste de Kamina
UML : Unified Modeling Language
UP : Unified Proccess
R.O.I : Règlement d’ordre intérieur
SGBD : Système de Gestion de Base de Données

VII
Table des matières

EPIGRAPHE ............................................................................................................................................ I
DEDICACE ............................................................................................................................................. II
REMERCIEMENTS ............................................................................................................................. III
INTRODUCTION GENERALE ........................................................................................................... 1
PRESENTATION DU SUJET ................................................................................................................. 1
1. OBJECTIF DE LA RECHERCHE ................................................................................................... 1
2. CHOIX ET INTERET DU SUJET ................................................................................................... 2
3. PROBLEMATIQUE ET HYPOTHESE ........................................................................................... 2
3.1. PROBLEMATIQUE................................................................................................................... 2
3.2. HYPOTHESE.............................................................................................................................. 3
4. METHODE ET TECHNIQUE ......................................................................................................... 4
4.1. METHODES ............................................................................................................................... 4
4.2. TECHNIQUE .............................................................................................................................. 6
4.3. SOURCE DES DONNEES ......................................................................................................... 6
5. DELIMITATION DU SUJET .......................................................................................................... 7
6. SUBDIVISION DU TRAVAIL ........................................................................................................ 7
CHAPITRE PREMIER : GENERALITES ......................................................................................... 9
II.1 INTRODUCTION .............................................................................................................................. 9
I.2 DEFINITIONS DES CONCEPTS ...................................................................................................... 9
I.3 CONSIDERATION THEORIQUE ................................................................................................... 13
1.3.1. PRESENTATION DE LA METHODE ET LA NOTATION UTILISEE ............................. 13
A. METHODE UP (unified process) ................................................................................................... 13
B. NOTION UTILISEE : UML ................................................................................................................. 15
1.3.2 LA PLATE FORME DE DEVELOPPEMENT DES APPLICATIONS ................................ 18
1.3.3 THEORIE SUR LA GESTION DES DONNEES ..................................................................... 19
CHAPITRE DEUXIEME : PRESENTATION DU CHAMP D’ETUDE ET ANALYSE DE
L’EXISTANT ........................................................................................................................................ 21
I. INTRODUCTION .......................................................................................................................... 21
II. PRESENTATION DU CHAMP D’ETUDE................................................................................... 21
II.2.1. DESCRIPTION DU DOMAINE .............................................................................................. 21
II.2.1.1. HISTORIQUE ......................................................................................................................... 21
II.2.1.2. SITUATION GEOGRAPHIQUE.......................................................................................... 22
VIII
II.2.1.3. ORGANIGRAMME HIERARCHIQUE ...................................................................... 23

II.3. ANALYSE DE L’EXISTANT ........................................................................................................ 25
A. ETUDE PRELIMINAIRE ........................................................................................................... 25
1. PROCESSUS METIER ................................................................................................................ 25
2. MODELE DE CONTEXTE STATIQUE (Diagramme de CU METIER)............................... 26
3. DIAGRAMME D’ACTIVITES ................................................................................................... 27
B. CAPTURE DES BESOINS FONCTIONNELS ........................................................................................ 28
1. DIAGRAMME DE CAS D’UTILISATION ............................................................................................ 28
2. DESCRIPTION TEXTUELLE DU DIAGRAMME DE CAS D’UTILISATION .................. 31
3. DIAGRAMME DE SEQUENCE SYSTEME............................................................................. 32
C. ETUDE DES SUPPORTS D’ECHANGES INFORMATIONNELS........................................ 40
II.5.1. ETUDE DES DOCUMENTS .................................................................................................... 40
II.5.2. DIAGRAMME DE CLASSES DU DOMAINE ....................................................................... 41
D. PRESENTATION DU DIAGNOSTIC DE L’EXISTANT ........................................................ 43
1. CRITIQUE DE L’EXISTANT .................................................................................................... 43
2. PROPOSITION DE LA SOLUTION NOUVELLE .................................................................. 43
CHAPITRE TROISIEME : CONCEPTION DETAILLEE DU SYSTEME INFORMATIQUE . 44
III.1. INTRODUCTION ......................................................................................................................... 44
III.2. NOTION DU DIAGRAMME DE SEQUENCE CONCEPTION ................................................. 44
III.3 NOTION DE DIAGRAMME DE CLASSES PARTICIPANTES ................................................. 49
III.4. DIAGRAMME DE CLASSES CONCEPTION ......................................................................................... 55
CHAPITRE QUATRIEME : ARCHITECTURE TECHNIQUE ET IMPLEMENTATION ..................................... 56
0. INTRODCUTION ............................................................................................................................... 56
I. CHOIX DE TECHNOLOGIES............................................................................................................... 56
A. Plateforme de développement ...................................................................................................... 56
B. Moyen de sauvegarde de données ................................................................................................ 57
II. ARCHITECTURE DE DEPLOIEMENT ....................................................................................... 58
1. Diagramme de déploiement ........................................................................................................... 58
III. IMPLEMENTATION ................................................................................................................. 59
III.1. Présentation des classes de dialogues .......................................................................................... 59
1
INTRODUCTION GENERALE
PRESENTATION DU SUJET
Sous tous les cieux l’information est considérée comme le support des
connaissances humaines et des communications dans tous les domaines de la vie. De ce fait,
l’informatique intervient comme une science du traitement automatique de l’information grâce à
son outil qu’on appelle ordinateur qui facilitera le traitement automatique et le partage rapide de
l’information.
Vu l’essor de l’informatique de nos jours, il est préférable de dire qu’à l’aide de son
outil (ordinateur), cette science permet à rendre élémentaire des tâches complexes que l’homme
ne peut pas résoudre dans peu de temps tels que ; les calculs complexes, le partage de l’information
et voir le stockage d’une masse d’informations pour une utilisation future. A cet effet, grâce à la
réduction du temps d’exécution et le partage de l’information d’une manière rapide, il est
indispensable dans le cadre de notre travail de fin cycle, d’aborder le sujet qui traite sur « La Mise
en place d’une application informatique de vidéo-conférence au sein d’une région épiscopale,
cas de la région épiscopale du Nord-Katanga, Tanganyika et Tanzanie »
Plus les bureaux dans la région épiscopale sont nombreux, plus la transmission de
l’information est trop lente pour être diffuser dans chaque bureau, ce pourquoi la mise en place
d’une application informatique de vidéo-conférence sera une solution favorable pour la
transmission de l’information, le partage et surtout la tenue d’une réunion au sein de ladite région
épiscopale en temps réel.
1. OBJECTIF DE LA RECHERCHE
L’objectif poursuivi dans notre recherche est d’apporter une solution meilleure à la
Région Episcopale du Nord-Katanga qui permettra de réduire le coût et maximiser le temps de
partage dans un premier temps et dans le second temps de valoriser cette grande Région Episcopale
d’une nouvelle technologie en termes d’équipements informatiques.
2
2. CHOIX ET INTERET DU SUJET

a. Choix du sujet
Le choix d’un sujet de la recherche scientifique n’est pas un hasard. Nous avons
choisi ce sujet dans le but de contribuer au gain du temps concernant le partage d’informations et
la tenue de réunions en temps réel au sein de la région épiscopale en apportant une solution
informatique.
b. Intérêt du sujet
 Du point de vue scientifique
Ce grand travail servira à ceux qui viendront après nous comme référence ou
point de repère afin d’en apporter une augmentation ou une modification.
 Du point de vue social
Pour la région épiscopale, l’application informatique de vidéo-conférence sera un

atout qui allégera la tâche da la tenue d’une réunion avec tous les membres qui se trouvent à un
autre endroit et partage d’information en temps réel.
 Du point de vue personnel
A la fin de la réalisation de ce travail, nous aurons une maitrise des connaissances

supplémentaire et nous nous évaluerons en tenant compte du travail réalisé et son importance dans
la communauté.
3. PROBLEMATIQUE ET HYPOTHESE
3.1.PROBLEMATIQUE
Les obligations d’une recherche scientifique imposent qu’il soit signifié les
problèmes pour lesquels l’étude est menée.
La problématique est définie comme étant un ensemble de questions qu’une science

ou une philosophie se pose dans un domaine particulier.1
1
Dictionnaire français, Larousse illustré, éd. Maury-Manche court, 2010, P.822
3
Elle est encore définie pour ainsi dire, ensemble des questions fondamentales aux
quelles la recherche doit trouver la réponse ou la satisfaction.2
Il est indispensable de savoir que la tenue des réunions au sein de la région
épiscopale pose des sérieux problèmes tel que :
 La perte du temps dans transmission des informations : il faut attendre que celui
qui a reçu l’information auprès de l’Evêque puisse aller à la bureautique faire la saisie, l’impression
et multiplier les copies pour transmettre les informations, tout cela a comme conséquence la perte
de temps.
 Manque de la confidentialité de l’information : étant donné que la région épiscopale
manque les agents dans le département de l’informatique, ses informations sont à la portée de tout
le monde, par conséquent les informations considérées secrètes seront diffusé par n’importe qui et
cela peut nuire à la région épiscopale.
Pour toutes les difficultés énumérées ci-haut, notre problématique s’articule autour
de la question suivante « Avec quelle technologie informatique peut-on utiliser pour faciliter la
tenue des réunions au sein de la région épiscopale en temps réel afin que le partage d’informations
soit immédiat ? »
3.2.HYPOTHESE
GRAWITZ définit l’hypothèse de travail ou de recherche comme une

réponse provisoire donnée aux questions de la problématique. Elle servira de fil conducteur, car
elle est une proposition de réponses à la question posée.3
Une hypothèse est une proposition ou une explication que l'on se contente d'énoncer
sans prendre position sur son caractère véridique, c'est-à-dire sans l'affirmer ou la nier. Il s'agit
donc d'une simple supposition, appartenant au domaine du possible ou du probable. Une fois
2
KITAMBA Odon, méthodes de recherche en science économique, G2 ECO, Cours inédit, UNIKAM,
2007, p.10.
3
GRAWITZ, Méthodes de sciences sociales, 5e édition, 1975, p. 403
4
énoncée, une hypothèse peut être étudiée, confrontée, utilisée, discutée ou traitée de toute autre
façon jugée nécessaire, par exemple dans le cadre d'une démarche expérimentale.4
Pour remédier aux difficultés rencontrées ci-haut au sein de la région épiscopale

pour ce qui est de la tenue des réunions et partage d’informations et pour répondre à la question
de la problématique, nous proposons une solution favorable qui est « La Mise en place d’une
application informatique de vidéo-conférence au sein de la Région Episcopale »
Quant à la perte du temps dans la transmission d’informations, notre application

sera dotée d’un système de messagerie, d’appels vidéo et d’alerte de son pour que la personne
concernée soit au courant immédiatement.
Pour la confidentialité, notre application sera dotée d’un système permettant à

chaque utilisateur de voir ou d’entendre les informations qui lui concerne.
4. METHODE ET TECHNIQUE
Tout travail scientifique doit avoir une méthode et une technique afin de mener
une bonne recherche.
4.1.METHODES
PINTO ET GRAWITZ, cités par Adrien MULUMBATI NGASHA ont défini le

mot méthode comme l’ensemble des opérations intellectuelles par lesquelles une discipline
cherche à atteindre les vérités qu’elle poursuit les démontrent et les vérifie5
Pour ce qui est de notre travail de fin cycle nous allons utiliser deux types de
méthodes : la méthode de recherche scientifique et la méthode d’analyse et conception de système
d’informations.
4
http://www.wikipedia.com/hypothèses, le 04/02/2019 à 13h35.
5
A. MULUMBATI NGASHA, introduction à la science politique, 3e éd. AFRICA, 2010, p. 16
5
a. Méthode scientifique
Désigne l’ensemble des canons guidant le processus de production des

connaissances scientifique, qu’il s’agisse d’observations, de raisonnement ou de calculs
théoriques.6
La démarche qui nous a permis de justifier l’objectif de notre recherche c’est la

méthode inductive qui part d’observations ou d’interventions ou d’interviews et mène à une
hypothèse ou un modèle scientifique.
b. Méthode d’analyse et Conception de Système d’information
Les méthodes de conception de systèmes d’information ont pour objectif de

permettre la formalisation des étapes préliminaires du développement d'un système, afin de rendre
ce développement le plus fidèle possible aux besoins du client. 7
Il existe plusieurs méthodes d'analyse et conception du système d’information (UP,

RUP, MERISE, PRAXEME), la méthode qui sera utilisé tout au long de travail c’est la méthode UP
(Unified Process) en français Processus unifié.
La gestion d’un tel processus est organisée d’après les 4 phases suivantes: Insertion,
élaboration, construction et transition.
 La phase d’insertion (Lancement).

 La phase d'élaboration.
 La phase de construction.
 Enfin, la phase de transition.
A l’intérieur de ces 4 phases, on mène différentes activités : expression des besoins,

analyse, conception, implémentation, test et déploiement.
6
http://www.wikipedia.net/methode_scientifique, 04/02/2019 à 14h20.
7
http://www.wikipedia.net/méthodes_conception_systemeinformation, 04/02/2019 à 14h22.
6
4.2.TECHNIQUE
Une technique est l’ensemble d’outils importants permettant au chercheur de

récolter et de traiter les données de sa recherche8.
Dans le but de réaliser une analyse et une conception concrète par rapport à la
problématique, nous avons utilisé les techniques suivantes :
 La technique documentaire : elle est basée sur la consultation des ouvrages, des travaux
de fin de cycle, des notes de cours, etc. Pour recueillir certaines informations concernant un objet
précis. Cette technique nous a permis de récupérer les données qui se trouver dans les documents
au sein de la région épiscopale.
 La technique d’observation : par définition, c’est une technique qui, grâce à elle le
chercheur entre personnellement en contact avec la réalité qu’il étudie. Cette technique nous a
aidés par une simple observation, à récolter les informations en rapport avec notre sujet.
 la technique d’interview : cette technique nous a permis d’entrer en contact direct avec les
différentes personnes travaillant au sein de la région épiscopale pour la récolte de certaines
informations.
4.3.SOURCE DES DONNEES
Une source ou source d'information est l'origine d'une information. Le concept de

« source» ne doit pas être confondu avec celui de « référence ». Une référence ne prétend qu'à
l'identification objective et raisonnée d'éléments bibliographiques, dont le nom de l'auteur, relatifs
au document. Quant à la source, elle permet de porter un jugement sur la validité d’une information
puisqu’elle tend à déceler et à rendre compte des intentions des médias producteurs d’information.
Autrement dit : se renseigner sur la source, ce s’intéresser à la nature et au lieu originel de discours
d’une information. Cela permet, entre autres, de mettre en évidence sa véracité, sa pertinence, et
l’utilité de son utilisation.9
8
http://www.wikipedia.net/technique, 04/02/2019 à 15h00.
9
http://fr.m.wikipedia.org/wiki/Source(information), 04/02/2019 à 15h05.
7
Dans l’élaboration de ce travail de fin de cycle, nous avons utilisé deux sources
d’informations :
1. Documentation
Cette source consiste à fouiller, analyser différents documents en extraire ce dont
nous avons besoin pour la réalisation du travail. Elle nous a permis de faire un bon regroupement
des informations en consultant divers documents relatif au sujet d’étude et ce document qui restent
la source même par excellence des données nécessaire pour la rédaction d’un travail scientifique
en informatique.
2. L’Internet
Cette source nous a permis de faire de consultation sur certaines informations non
trouvé dans les documents et cela a permis d’avoir une bonne compréhension sur les informations
recherchées.
5. DELIMITATION DU SUJET
Notre travail se limite à la région Episcopale du Nord-Katanga, Tanganyika et

Tanzanie, dans la période allant de 2018-2019.
6. SUBDIVISION DU TRAVAIL
Hormis l’Introduction Générale et la Conclusion Générale notre travail est

subdivisé en quatre chapitres, reparti de la manière suivante :
 Chapitre premier est intitulé : « GENERALITES », dans ce chapitre nous allons donner
un aperçu des concepts de base du domaine d’application ainsi que la définition de
l’informatique, enfin présenter la méthode utilisée.
 Le deuxième chapitre s’étale sur : « PRESENTATION DU CHAMP D’ETUDE ET

ANALYSE DE L’EXISTANT ». Donne une description détaillée du domaine, l’étude de
l’existant ou du système (les acteurs qui interviennent dans ce système), les besoins fonctionnels
des utilisateurs, enfin la critique de l’existant et la proposition de la solution nouvelle.
8
 Le troisième chapitre prend le thème : « CONCPTION DETAILLEE DU SYSTEME

INFORMATIQUE ». il s’agit ici de donner la conception du futur système sans toutefois faire
attention sur les techniques.
 Le quatrième chapitre parle sur : « ARCHITECTURE TECHNIQUE ET
IMPLEMENTATION ». Dans ce chapitre, nous déterminerons l’environnement de l’architecture
réseau du système d’information et nous allons programmer une application regroupant toutes les
spécifications conçues.
9
CHAPITRE PREMIER : GENERALITES

II.1 INTRODUCTION
Comme il est nécessaire pour chaque chapitre d’un travail scientifique d’avoir un
objectif à atteindre, celui-ci que nous voulions aborder a comme objectif de rendre clair et précis
quelques concepts clés utilisés dans le domaine d’application et de l’informatique. En outrance de
ce qui précède, un éclaircissement sur le système d’information, les méthodes d’analyses et de
conception des applications utilisées, la plateforme de développement des applications qui
permettra de mettre en œuvre l’application attendu par les utilisateurs et enfin nous présenterons,
tout cela pour bien expliciter la pensée exprimée dans ce travail de fin du premier cycle.
I.2 DEFINITIONS DES CONCEPTS

A. Définitions des concepts du domaine de l’application
Pour mieux comprendre notre travail qui s’intitule : « Mise en place d’une
application informatique de vidéo-conférence au sein d’une région épiscopale, cas de la région
épiscopale du Nord-Katanga, Tanganyika et Tanzanie »
a. Mise en place : C’est l’organisation et l’installation de ce qui est nécessaire (pour quelque
chose).10
b. Application
Une application est un programme, ou un ensemble de programmes, destiné à aider

l’utilisateur d’un ordinateur pour le traitement d’une tâche précise. 11
Selon le jargon informatique, une application est un programme assez important,
vu sous l’angle des tâches qu’il est censé mener à bien.
10
Dictionnaire français, Larousse Illustré, éd. Manche-Court, 2010, p
11
Copyright (©) Larousse 2009
10
c. Informatique
L’informatique est une science du traitement rationnel, notamment par des

machines automatiques, de l’information considérée comme support des connaissances humaines
et de communication dans le domaine technique, économique et sociaux.12
d. Vidéoconférence
La vidéo-conférence est un système visuel et auditif permettant de communiquer

oralement en temps réel et de façon interactive.13
Elle est encore définie comme une réunion des personnes par l’intermédiaire d’un
réseau, lors de laquelle on s’échange du texte mais surtout des images animées des participants et
les doux murmures de leurs voix.14
e. Région-épiscopale: La Région Episcopale est une subdivision ecclésiastique constituée de

plusieurs conférences annuelles.
B. Définition des concepts du domaine informatique
 Théorie sur l’information
Est un élément conceptuel permettant le transfert, le stockage et le traitement de la

connaissance.15
L’information est composée de deux mots :
 Donnée, une représentation conventionnelle d’une information sous une forme convenant
à son traitement par ordinateur.
12
Copyright (©) jargon informatique
13
http://www.wikepedia.com/vidéo-conférence, consulter le 05/02/2019 à 05h27’
14
15
11
 un sens qui dépend de chaque individu.
Les informations traitées par l'informatique sont de différentes natures ; des

nombres, du texte, des sons, des images, des clips vidéo etc. mais aussi les instructions des
programmes informatiques qui traitent tous ces types d'informations.
 Théorie sur le système d’information
Le système d’information (SI) est un ensemble organisé de ressources qui permet

de collecter, stocker, traiter et distribuer de l’information, en général grâce à un ordinateur. Il
s’agit d’un système sociotechnique composé de deux sous-systèmes, l’un social et l’autre
technique. Le sous-système social est composé de la structure organisationnelle et des personnes
liées au SI. Le sous-système technique est composé des technologies (hardware, software et
équipements de télécommunication) et des processus d’affaires concernés par le SI.16
Un système d’information se construit à partir de l’analyse des processus métier de

l’organisation et de leurs interactions/interrelations, et non simplement autour de solutions
informatiques plus ou moins standardisées par le marché. Le système d’information doit réaliser
l’alignement stratégique de la stratégie d’entreprise par un management spécifique.
Le Système d’information est le centre nerveux des entreprises. Tous les acteurs de
l’entreprise véhiculent des informations. L’objectif principal d’un système d’information (SI) consiste
à restituer l’information à la personne concernée sous une forme appropriée et au moment opportun.
Le système d’information a une double finalité :
a. une finalité fonctionnelle :
Le SI est un outil de communication et de coordination entre les différents services

et domaines de gestion de l'entreprise. Il doit produire et diffuser des informations nécessaires aux
opérations d'une part et aux choix stratégiques et tactiques d'autre part.
16
http://www.wikepedia.com/système information, à 04h05’ 06/02/2019
12
Le SI a donc un rôle opérationnel et stratégique. Il est opérationnel quand il se concentre sur des
tâches et des procédures de gestion automatisables (comptabilité, gestion, paie, commerciale,…).
Par contre, il est stratégique quand il intervient pour les prises de décisions.
L’analyse de l’entreprise en tant que système consiste à déterminer l’ensemble des flux et à
connaître la nature de l’information. Il faut distinguer 3 fonctions :
o Le contrôle : contrôlé la qualité de ce qui a été fait par le système opérant
o La coordination : il assure le suivi des actions qui sont menés dans l’entreprise.
o La décision : élaboration de prévisions, décisions d’arrêter la production d’un
produit qui n’est plus rentable.
2. une finalité sociale :
Il est à noter que le SI à une autre finalité qui concerne la vie dans l'entreprise, il
doit permettre l'intégration des salariés dans l'entreprise, ceci quel que soit leur niveau dans la
hiérarchie.
Il doit favoriser la connaissance de l'entreprise et la compréhension des choix
stratégiques par l'ensemble du personnel. De plus, il permet de développer un "esprit d'entreprise"
chez les salariés en facilitant, par la diffusion de l'information, une vie sociale et une culture
d’entreprise.
 Théorie sur le système
Le système est défini comme un ensemble d’éléments interagissant entre eux selon
certains principes ou règles.17
Un système est déterminé par :
 Une frontière qui le délimite par rapport à l’environnement dans lequel il est plongé ;
 Une finalité ou l’intention d’atteindre un objectif fixé ;
 Son évolution dans le temps (passé, présent et à venir) ;
17
http://www.wikepedia.com/systeme, 06/02/20019 à 04h20’
13
 Son organisation c’est-à-dire sa structure (les éléments qui le composent et les relations qui les
relient) ainsi que ses processus.
I.3 CONSIDERATION THEORIQUE

1.3.1. PRESENTATION DE LA METHODE ET LA NOTATION UTILISEE
A. METHODE UP (unified process)
Un processus définit une séquence d’étapes, en partie ordonnées, qui concourent à
l’obtention d’un système logiciel ou à l’évolution d’un système existant.18
L’objet d’un processus de développement est de produire des logiciels de qualité

qui répondent aux besoins de leurs utilisateurs dans des temps et des coûts prévisibles.
Le processus unifié (UP) est un processus de développement logiciel construit sur

UML ; il est itératif et incrémental, centré sur l’architecture, conduit par les cas d’utilisation et
piloté par les risques.19
Tout processus UP répond aux caractéristiques ci-après.
 Il est itératif et incrémental. Le projet est découpé en itérations de courte durée (environ
1 mois) qui permettent de mieux suivre l'avancement global. A la fin de chaque itération, une partie
exécutable du système final est produite, de façon incrémentale. Un incrément est une quantité
prédéfinie ajoutée à une variable à chaque exécution d’un programme itératif.
 Processus orienté par la réduction des risques: Dans ce cadre, les causes majeures
d’échec d’un projet logiciel doivent être écartées en priorité. Nous identifions une première cause
provenant de l’incapacité de l’architecture technique à répondre aux contraintes opérationnelles,
et une seconde cause liée à l’inadéquation du développement aux besoins des utilisateurs.
 Piloté par les cas d'utilisation. Le projet est mené en tenant compte des besoins et des
exigences des utilisateurs. Les cas d'utilisation du futur système sont identifiés, décrits avec
précision et priorisés.
Pascal Roques, Franck Vallée, UML 2 en action de l’analyse des besoins à la conception, éd.
18
Eyrolles, 4eme édition, 2007, p.12.

19
Ibidem
14
 Centré sur l'architecture. Les auteurs d’UP mettent en avant la préoccupation de

l’architecture du système dès le début des travaux d’analyse et de conception. Il est important de
définir le plus tôt possible, même à grandes mailles, l’architecture type qui sera retenue pour le
développement, l’implémentation et ensuite le déploiement du système.
La gestion d’un tel processus est organisée d’après les 4 phases suivantes: Insertion,
élaboration, construction et transition.
- La phase d’inception (Lancement). Cette phase correspond à l'initialisation du projet

conduit où l’on mène une étude d’opportunité et de faisabilité du système à construire. Une
évaluation des risques est aussi réalisée dès cette phase.
- La phase d'élaboration poursuit trois objectifs principaux en parallèle :
 Identifier et décrire la majeure partie des besoins utilisateurs;
 Construire (et pas seulement décrire dans un document) l'architecture de base du
système;
 Identifier les risques majeurs du projet.
- La phase de construction consiste surtout à concevoir et implémenter l'ensemble des
éléments opérationnels (autres que ceux de l'architecture de base). C'est la phase la plus
consommatrice en ressources et en efforts.
- Enfin, la phase de transition permet de faire passer l'application des développeurs aux
utilisateurs finaux. Les mots-clés sont : conversion des données, formation utilisateurs,
déploiement, bêta tests.
Les activités du processus.
Les activités menées à l’intérieur des quatre phases sont plus classiques, car déjà
bien documentées dans les méthodes existantes par ailleurs. Nous nous limiterons donc à ne donner
qu’une brève explication de chaque activité. 20
20
Joseph Gabay, David Gabay, UML 2 Analyse et Conception, DUNOD, Paris, 2008, p.116
15
Expression des besoins : UP propose d’appréhender l’expression des besoins en se fondant sur
une bonne compréhension du domaine concerné pour le système à développer et une modélisation
des procédures du système existant.
Ainsi, UP distingue deux types de besoins :
 les besoins fonctionnels qui conduisent à l’élaboration des cas d’utilisation,

 les besoins non fonctionnels (techniques) qui aboutissent à la rédaction d’une matrice des
exigences.
Analyse : L’analyse permet une formalisation du système à développer en réponse à l’expression

des besoins formulée par les utilisateurs. L’analyse se concrétise par l’élaboration de tous les
diagrammes donnant une représentation du système tant statique (diagramme de classe
principalement), que dynamique (diagramme des cas d’utilisation, de séquence, d’activité, d’état-
transition…).
Conception : La conception prend en compte les choix d’architecture technique retenus pour le
développement et l’exploitation du système. La conception permet d’étendre la représentation des
diagrammes effectuée au niveau de l’analyse en y intégrant les aspects techniques plus proches
des préoccupations physiques.
Implémentation : Cette phase correspond à la production du logiciel sous forme de composants,

de bibliothèques ou de fichiers. Cette phase reste, comme dans toutes les autres méthodes, la plus
lourde en charge par rapport à l’ensemble des autres phases (au moins 40%).
Test : Les tests permettent de vérifier : La bonne implémentation de toutes les exigences
(fonctionnelles et techniques), Le fonctionnement correct des interactions entre les objets et la
bonne intégration de tous les composants dans le logiciel.
B. NOTION UTILISEE : UML
UML (Unified Modeling Language en anglais soit langage de modélisation unifiée)

se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire
des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles,
16
concevoir des solutions et communiquer des points de vue. UML unifie à la fois les notations et
les concepts orientés objet.21
Les méthodes utilisées dans les années 1980 pour organiser la programmation
impérative (notamment Merise) étaient fondées sur la modélisation séparée des données et des
traitements. Lorsque la programmation par objets prend de l’importance au début des années 1990,
la nécessité d’une méthode qui lui soit adaptée devient évidente. Plus de cinquante méthodes
apparaissent entre 1990 et 1995 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD,
OOM, OOSE, etc.) mais aucune ne parvient à s’imposer. En 1994, le consensus se fait autour de
trois méthodes :
- OMT (Object Modeling Technique) de James Rumbaugh fournit une représentation graphique
des aspects statiques, dynamiques et fonctionnels d’un système.
- Booch (Object Oriented Developpement) de Grady Booch, introduit les concepts de

paquetage, diagramme de classes, diagramme d’objet et diagramme d’états ;
- OOSE (Object Oriented Software Engineering) d’Ivar Jacobson fonde l’analyse sur la
description des besoins des utilisateurs (cas d’utilisation ou use case).
Chaque méthode avait ses avantages et ses partisans. Le nombre de méthodes en

compétition s’était réduit, mais le risque d’un éclatement subsistait: la profession pouvait se diviser
entre ces trois méthodes, créant autant de continents intellectuels qui auraient du mal à
communiquer.
Événement considérable et presque miraculeux, les trois gourous qui régnaient

chacun sur l’une des trois méthodes se mirent d’accord pour définir une méthode commune qui
fédérerait leurs apports respectifs (on les surnomme depuis «the Amigos»). UML (Unified
Modeling Language) est né de cet effort de convergence. L’adjectif unified est là pour marquer
qu’UML unifie, et donc remplace.
21
P. roques, UML 2.0 modéliser une application web, éd. Eyrolles, paris 2004, p.50
17
En fait, et comme son nom l’indique, UML n’a pas l’ambition d’être exactement
une méthode : c’est un langage.
La version d’UML en cours à la fin 2006 est UML 2.0 et les travaux d’amélioration
se poursuivent.
UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues
distinctes pour représenter des concepts particuliers du système d’information. Ils se répartissent
en deux grands groupes :
Diagrammes structurels ou diagrammes statiques
 Diagramme de classes (Class diagram) : Il représente l’architecture conceptuelle du

système : il décrit les classes que le système utilise, ainsi que leurs liens.
 diagramme d’objets (Object diagram) : Le diagramme d’objets permet d’éclairer un

diagramme de classes en l’illustrant par des exemples.
 diagramme de composants (Component diagram) : Il montre des structures complexes,

avec leurs interfaces fournies et requises.
 diagramme de déploiement (Deployment diagram) : Le diagramme de déploiement montre

le déploiement physique des artefacts sur les ressources matérielles.
 diagramme de paquetages (Package diagram) : Ce diagramme montre la communication

entre les paquetages de système, et les relations de dépendance entre packages qui aident à rendre
visibles les éléments publics de l’un des packages au sein d’un autre.
 diagramme de structures composites (Composite structure diagram) : Il montre

l’organisation interne d’un élément statique complexe.
Diagrammes comportementaux ou diagrammes dynamiques
 diagramme de cas d’utilisation (Use case diagram) : Il représente la structure des grandes
fonctionnalités nécessaires aux utilisateurs du système.
18
 diagramme d’activités (Activity diagram) : ce diagramme montre l’enchaînement des

activités qui concourent au processus.
 diagramme d’états-transitions (State machine diagram) : Le diagramme d’états-transitions

représente la façon dont évoluent les objets appartenant à une même classe.
 Diagrammes d’interaction (Interaction diagram) : Ils permettent d’établir un lien entre les
diagrammes de cas d’utilisation et les diagrammes de classes : ils montrent comment des
objets communiquent pour réaliser une certaine fonctionnalité
 diagramme de séquence (Séquence diagram) : Le diagramme de séquence représente la

succession chronologique des opérations réalisées par un acteur.
 diagramme de communication (Communication diagram) : Il montre la communication

entre objets dans le plan au sein d’une interaction.
 diagramme de temps (Timing diagram) : Il fusionne les diagrammes d’états et de séquence

pour montrer l’évolution de l’état d’un objet au cours du temps.
Chacun d’eux est dédié à la présentation des concepts particuliers d’un système
logiciel. Mais tous ne seront pas adapté dans notre modélisation quelque uns, notamment :
diagramme d’activité, diagramme de cas d’utilisation, diagramme de classes, diagramme de
séquence et diagramme de déploiement.
1.3.2 LA PLATE FORME DE DEVELOPPEMENT DES APPLICATIONS

Une plate-forme est en informatique une base de travail à partir de laquelle on peut
écrire, lire, développer et utiliser un ensemble de logiciels. Elle peut être composée du système
d’exploitation, d’outils logiciels de développement (bibliothèque logicielle, API voire
frameworks: Struts, Hibernate, etc.), des débogueurs, éditeur de texte, compilateurs et éditeur de
liens voire Environnement de développement intégré : Visual Studio, Eclipse, Netbeans, etc., de
SGBD, d’un serveur web (Apache, IIS, etc.), d’un serveur d'applications (JOnAS, Tomcat, JBoss,
etc.), etc.
19
1.3.3 THEORIE SUR LA GESTION DES DONNEES
1. Une base des données qu’est-ce ?

Selon Gilles Roy, Une base de données c’est un ensemble structuré d’éléments
d’information, souvent agencés sous forme de tables, dans lesquels les données sont organisées
selon certains critères en vue de permettre leur exploitation pour répondre aux besoins
d’information d’une organisation.22
Une base de données est composée de données stockées dans des mémoires de
masse sous forme structurée et accessible par des applications différentes et des utilisateurs
différents .elle est utilisée par plusieurs personnes en même temps, cette dernière est structuré mais
sa structuration doit avoir un caractère universel, il ne faut pas que cette structure soit adapter à
une application particulière, mais qu’elle puisse être utilisable par plusieurs applications.
La conception des bases de données se réfère à des activités qui mettent l'accent sur
la conception de la structure des bases de données qui sera utilisée pour stocker et gérer les données
de l'utilisateur final.
2. Le système de gestion de base des données qu’est-ce ?
Le système de gestion de base de données SGBD en sigle est un logiciel qui prend
en charge la structuration, le stockage, la mise à jour et la maintenance d'une base de données. Il
est l'unique interface entre les informaticiens et les données (définition des schémas,
programmation des applications), ainsi qu'entre les utilisateurs et les données (consultation et mise
à jour).23
Un tel système permet de lire, écrire, modifier, trier, transformer ou même imprimer
les données qui sont contenus dans la base de données.
Parmi les logiciels les plus connus il est possible de citer : MySQL, PostgreSQL,
SQLite, Oracle Database, Microsoft SQL Server, Firebird ou Ingres.
Ces systèmes peuvent être catégorisés selon leur fonctionnement :
22
GILLE ROY, Conception de base de données avec UML, presses de l’université de Québec,
2003, p.50
23
http://scenari-plateforme.org/mobile-source/opale-demo/sgbd, 10/05/2019 à 12h01
20
 Système propriétaire : Oracle Database, Microsoft SQL Server, DB2, MaxDB, 4D, dBase,
Informix, Sybase
 Système libre MySQL, PostgreSQL, MariaDB, Firebird, Ingres, HSQLDB, Derby
 Orienté objet : ZODB, db4o
 Embarqué : SQLite, Berkeley DB
 NoSQL : Cassandra, Redis, MongoDB, SimpleDB, BigTable, CouchDB, HBase,
LevelDB, RethinkDB, Memcached
 Autre système : Access, OpenOffice.org Base, FileMaker, HyperFileSQL, Paradox, Neo4j
21
CHAPITRE DEUXIEME : PRESENTATION DU CHAMP

D’ETUDE ET ANALYSE DE L’EXISTANT
I. INTRODUCTION
Ce chapitre est consacré à l’étude de l’organisation, en présentant son existant, il
permet de situer géographiquement ladite organisation et d’avoir une idée claire sur la structure
organisationnelle de son fonctionnement. Ce dernier analyse tout le métier, les déroulements des
activités et permet d’appréhender deux points de vue, la structure statique et comportementale. Il
s’agit de deux perspectives différentes qui aident à compléter la compréhension du système à
développer.
Dans ce même ordre d’idée, il modélise le diagramme de cas d’utilisation métier,
le diagramme d’activité du processus métier, le diagramme de cas d’utilisation et leurs descriptions
textuelles, le diagramme de séquence système ainsi que le diagramme de classes du domaine qui
sera vu dans la suite ci-dessous.
II. PRESENTATION DU CHAMP D’ETUDE
II.2.1. DESCRIPTION DU DOMAINE
II.2.1.1. HISTORIQUE
L’Eglise Méthodiste-Unie au Katanga a commencée avec Mr Kaluwashi et John
Springer. Ce dernier est un fait connu comme le fondateur de l’Eglise Méthodiste-Unie au
Katanga.
En 1917, Mr Springer pensa à la fondation d’un poste de mission chez les Baluba.
Avec Springer et Mme Helen Emily, Mr Smyres prirent le train d’Elisabeth ville (Lubumbashi)
jusqu’à Bukama. A Bukama, les Springer prirent le bateau jusqu’à Kinkonja et près de la mission
Mwanza ou ils trouvèrent Mr Kaluwashi aidant M. Burton fondateur de la mission Congo
Evangélistique.
En 1922, Mr Springer, M.Shield, M. Dama et les autres arrivèrent à Kanene ou ils

fondèrent une mission et choisirent Kanene afin d’y ouvrir une école appelée « Congo Institute »
En 1924 Mr Smyres fut désigné pour Kanene, en même temps Mr et Mme Ray
Swanlley arrivèrent à Elisabeth ville et s’installent à Kanene.
22
En 1940, Le Congo Institute fut transféré de Kanene à Mulungwishi et devint le

Springer Institute.
L’élection du Révérend Snow Booth comme évêque en 1944 donna une nouvelle
et forte impulsion à la croissance rapide du travail du Séjour au Congo.
En 1968, l’église Méthodiste-Unie, le Nord-Katanga devenant ainsi la conférence

annuelle provisoire du Nord-Katanga avec un total de quatre districts qui sont : Kalemie, Manono,
Malemba et Kabongo sous l’épiscopal de l’évêque John Wesley Shungu.
II.2.1.2. SITUATION GEOGRAPHIQUE

Le Bureau de la Région Episcopale du Nord-Katanga, Tanganyika et Tanzanie est
situé sur l’avenue de la base contre l’avenue Sendwe N°20, dans la ville de Kamina, Province du
Haut-Lomami.
23
II.2.1.3. ORGANIGRAMME HIERARCHIQUE
EVEQUE
Secrétariat Episcopal Secrétariat Administratif Secrétariat chargé de suivi et Secrétariat de bien de

exploitation l’église
Représentation légal suppléant chargé Représentation légal chargé du Représentation légal chargé de la vie
de leadership développement de l’église
Trésorerie Générale
Trésorerie de la conférence annuelle
Figure 1: Organigramme du Bureau Episcopal
Source : Représentant Légal Suppléant chargé de Vie de l’église

24
II.2.1.4. Fonctionnement
1. Evêque : ses attributions statutaires et stipulées dans le R.O.I, pour ce faire avec l’appui
du Bureau Episcopal :
il convoque et préside la conférence annuelle
il gère les finances de la conférence annuelle
il autorise l’achat et la vente des biens meubles et immeubles en cas d’urgence.
Il engage, gère et sanctionne le personnel du secteur privé et public conformément à la
législation, où à la convocation du travail.
Il représente l’Eglise à l’égard des tiers et en justice, en personne ou par substitution.
2. Secrétariat Episcopal : en d’autres termes le secrétaire particulier ou permanent du Mgr
Evêque, il assume sous la dépendance directe de l’Evêque les responsabilités ci-après :
Assister l’Evêque en tout lieu de rendez-vous des services ou réunions convoquées par
l’Evêque.
Planifier, ordonner, assurer et rapporter la gestion quotidienne du Bureau Episcopal.
Confectionner le PV des réunions ténues par l’Evêque.
Assister l’Evêque dans l’élaboration de l’ordre du jour des réunions.
3. Secrétariat Administratif : sous la direction de l’Evêque, le Secrétariat Administrait a les
responsabilités suivantes :
s’assurer la coordination des programmes du Bureau Episcopal
la porte d’entrée, du traitement et du suivi et classement du courrier.
Gérer le personnel engagé et temporaire de l’UMK
Assurer la transmission des rapports à l’Evêque
Assurer la collaboration parfaite entre les responsables régionaux.
4. Secrétariat chargé de suivi et exploitation : sous la supervision de l’Evêque, ce dernier
assume les responsabilités suivantes :
Suivi des applications des mesures et règlements produits sur PV des assemblées ou
conférences.
Produire le rapport d’exploitation des décisions des assemblées les districts, les paroisses
et les départements.
5. Secrétariat chargé de bien de l’église : sous la supervision de l’Evêque, ce dernier assume
les responsabilités suivantes :
25
Assurer l’archivage de tous les documents légaux et cadastraux des biens de l’église.
Tenir documents d’inventaire et fiches de tous les biens meubles et immeubles.
Veiller à leur existence physique.
6. Trésorerie Général : sous la supervision directe de l’Evêque gère les responsabilités
suivantes :
Ensemble avec tous les gestionnaires, prépare et établi le budget de l’UMC
Assurer la tenue de la comptabilité
Assurer l’exécution rationnelle du budget
Rendre compte la gestion journalière à l’Eglise.
Préparer les rapportages financiers à soumettre aux différents comités et conférence
intéressées.
7. Trésorerie à la conférence annuelle :
Gérer les comptes bancaires et la caisse de la conférence annuelle
Assurer la tenue des comptes à la conférence annuelle
Consigner avec la trésorerie générale ou l’Evêque les documents autorisant les retraits en
compte.
II.3. ANALYSE DE L’EXISTANT
A. ETUDE PRELIMINAIRE
1. PROCESSUS METIER
- L’Evêque planifie la réunion.
- Le secrétariat Episcopal reçoit la planification de la réunion et transmet la planification au
secrétariat Administratif
- Ce dernier rédige la lettre de convocation.
- Cette lettre une fois parvenue aux participants à la réunion
- Tenue de la réunion.
- Le secrétariat Episcopal rédige un compte rendu de la réunion
- Ce compte rendu sera approuvé par l’Evêque
- Après avoir approuvé le compte rendu, le secrétariat Episcopal doit transmettre les copies du
compte rendu au secrétariat Administratif.
- Le secrétariat Administratif transmet les copies aux concernés.
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 U
26
EA 9.0
2. Unregistered
MODELE DE Trial Version EA STATIQUE
CONTEXTE 9.0 Unregistered Trial Version
(Diagramme EA METIER)
de CU 9.0 Unregistered Trial Version EA 9.0 U
Le diagramme de contexte statique délimite le domaine d’étude en précisant
ce qui est à la charge du système et
en identifiant l’environnement extérieur au système étudié avec lequel ce dernier
communique.
Ses composants sont :

Les acteurs externes. Un acteur externe est une entité externe au système étudié qui
interagit avec le système.
Un processus unique symbolisant le Système Information étudié : Nom Du SI
Echange entre le système étudié et son environnement.

class Deployment Model
SYSTEME DE
VIDEO-CONFERENCE
Participant
Compte rendu
S.AD Registre de lettre

S.EP EVEQUE
Figure 2: Diagramme de cas d'utilisation métier

27
3. DIAGRAMME D’ACTIVITES
Le diagramme d’activités n’est autre que la transcription dans UML de la

représentation du processus telle qu’elle a été élaborée lors du travail qui a préparé la modélisation
: il montre l’enchaînement des activités qui concourent au processus.24
Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils
sont donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de
flots de données. Ils permettent ainsi de représenter graphiquement le comportement d’une
méthode ou le déroulement d’un cas d’utilisation.
24
Laurent AUDIBERT, Op.cit., p.23
28
act Deployment Model
EVEQUE SECRETAIRE EPISCOPAL SECRETAIRE PARTICIPANT

ADMINISTRATIF
Planifier réunion
Transmettre
planification
Regider lettre covocation
Pesider réunion Tenir réunion Tenir réunion Tenir réunion
Rediger compte rendu

de la réunion
Approuver compte rendu
Transmettre copie
compte rendu Archiver copie et
transmettre copie aux
concernés
Figure 3: Diagramme d'activités
B. CAPTURE DES BESOINS FONCTIONNELS

1. DIAGRAMME DE CAS D’UTILISATION
Le diagramme de cas d’utilisation représente la structure des grandes

fonctionnalités nécessaires aux utilisateurs du système.25
25
DI GALLO Frédéric, Méthodologie des systèmes d’informations – UML, CNAM ANGOULEME 2000-
2001, p.34
29
Bien souvent, la maîtrise d’ouvrage et les utilisateurs ne sont pas des

informaticiens. Il leur faut donc un moyen simple d’exprimer leurs besoins. C’est précisément le
rôle des diagrammes de cas d’utilisation qui permettent de recueillir, d’analyser et d’organiser les
besoins, et de recenser les grandes fonctionnalités d’un système. Il s’agit donc de la première étape
UML d’analyse d’un système.
C’est le premier diagramme du modèle UML, celui où s’assure la relation entre

l’utilisateur et les objets que le système met en œuvre.
Les éléments des diagrammes de cas d’utilisation.
1. Acteur : entité externe qui agit sur le système ; Le terme acteur ne désigne pas seulement les
utilisateurs humains mais également les autres systèmes. Les acteurs sont des classificateurs qui
représentent des rôles au travers d'une certaine utilisation (cas) et non pas des personnes physiques.
Ce sont des acteurs types.26
Il se représente par un petit bonhomme avec son nom (i.e. son rôle) inscrit dessous.
Il est également possible de représenter un acteur sous la forme d’un classeur stéréotypé « actor ».
2. Cas d’utilisation : Un cas d’utilisation spécifie une fonction offerte par l’application à son
environnement. Un cas d’utilisation est spécifié uniquement par un intitulé.27
 Relations entre cas d’utilisation
1. Relation d’inclusion : Une relation d’inclusion d’un cas d’utilisation A par rapport à un cas
d’utilisation B signifie qu’une instance de A contient le comportement décrit dans B : le cas A
dépend de B. Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A. Cette
dépendance est symbolisée par le stéréotype «include »
2. Relation d’extension : On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le
cas d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut
éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est optionnelle.
26
Ibidem, p.34
27
Xavier Blanc, Isabelle Mounier, UML 2 pour les développeurs, éd. Eyrolles, p.98
30
Le cas de base peut fonctionner tout seul, mais il peut également être complété par un autre, sous
certaines conditions, et uniquement à certains points particuliers de son flot d’événements appelés
points d’extension. Cette dépendance est symbolisée par le stéréotype « extend ».
3. Relation de généralisation : Un cas A est une généralisation d’un cas B si B est un cas particulier
de A. Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes
UML et se traduit par le concept d’héritage dans les langages orientés objet.
 Relation entre acteur et cas d’utilisation.
1. Relation d’association : Une relation d’association est chemin de communication entre un

acteur et un cas d’utilisation et est représenté un trait continu.
 Relation entre acteurs
La seule relation possible entre deux acteurs est la généralisation: un acteur A est
une généralisation d’un acteur B si l’acteur A peut-être substitué par l’acteur B. Dans ce cas, tous
les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.
31
uc Deployment Model
Planifier
réunion
Gérer réunion
Se Connecter
Administrateur «i ncl ude»
Lister Status «i ncl ude»
Participants
«i ncl ude»
«i ncl ude»
Ajouter
«i ncl ude»
Participant
Authentification
«i ncl ude»
Supprimer
Participant
«i ncl ude»
Gérer
«i ncl ude»
Compte
Créer Compte
Participant Envoyer Accepter

Message «i ncl ude» Invitation
«i ncl ude»
Refuser
Chatter Invitation
Figure 4: Diagramme de cas d'utilisation
2. DESCRIPTION TEXTUELLE DU DIAGRAMME DE CAS D’UTILISATION
Le diagramme de cas d’utilisation décrit les grandes fonctions d’un système du

point de vue des acteurs, mais n’expose pas de façon détaillée le dialogue entre les acteurs et les
cas d’utilisation. Bien que de nombreux diagrammes d’UML permettent de décrire un cas, il est
recommandé de rédiger une description textuelle car c’est une forme souple qui convient dans bien
des situations.
32
3. DIAGRAMME DE SEQUENCE SYSTEME
L’objectif du diagramme de séquence est de représenter les interactions entre objets

en indiquant la chronologie des échanges. Cette représentation peut se réaliser par cas d’utilisation
en considérant les différents scénarios associés.28
Un diagramme de séquence se représente globalement dans un grand rectangle avec indication du

nom du diagramme en haut à gauche.
- Nom du cas d’utilisation : planifier réunion.

- Objectif : on planifie le programme de la réunion pour se préparer de quoi il sera question
et établir les ordres du jour.
- Acteur concerné : Administrateur
- Précondition : s’authentifier et être connecté au système.
- Scénario-nominal :
1. Saisir programme
2. Afficher aperçu
3. Envoyer programme
- Scénario-alternatif : néant
- Post-condition : afficher la page de menus
28
Joseph Gabay, David Gabay, Op.cit, p.90
33
Système
: Administrateur
1 : Saisir programme
2 : Afficher aperçu
3 : Envoyer programme
4 : Envoyer()
5 : Affichage page Menus
Figure 5: Diagramme de séquence système planifier réunion
- Nom du cas d’utilisation : Gérer réunions.

- Objectif : est d’avoir un contrôle sur la réunion tout en donnant différents droits aux
différents participants de la réunion.
- Précondition : il faut avoir le droit d’organisateur pour gérer la réunion.
- Scénario nominal :
1. Démarrer une réunion
2. Lister status participant
3. Attribuer un rôle aux participants.
- Scénario alternatif : néant
- Post-condition : Afficher page de menus
34
Système
: Administrateur
1 : Demarrer réunion
2 : Lister participant
3 : Attribuer rôles
Figure 6: Diagramme de séquence système Gérer réunions
- Nom du cas d’utilisation : Ajouter participant

- Objectif : pour permettre d’avoir de communication privé avec le participant concerné et
avoir un privilège d’augmenter le nombre des participants à la réunion.
- Précondition : être connecté au système.
1. Demander page participant
2. Affichage page participant
3. Saisir informations participant
4. Confirmer
5. Affichage page Menus
- Post-condition : afficher page d’accueil
35
Système
: Administrateur
1 : Demander page participant
2 : Affichage page participant
3 : Saisir Informations participant
4 : Confirmer
5 : Affichage page de menus
Figure 7: Diagramme de séquence système Ajouter participant
- Nom du cas d’utilisation : Gérer compte.

- Objectif : permettre d’avoir une sécurité sur les comptes et avoir un stock des comptes des
participants.
- Précondition : être connecté au système et un compte d’utilisateur au système.
1. Afficher page compte
2. Affichage de la page compte
3. Rechercher compte utilisateur
4. Affichage Résultat
5. Octroyer droit
6. Message de confirmation
- Post-condition : afficher la page d’accueil.
36
Système
: Administrateur
1 : Afficher page compte
2 : Affichage page compte
3 : Rechercher Compte User

4 : Affichage Resultat
5 : Octroyer droit
6 : Message Conformation
Figure 8: Diagramme de séquence système Gérer Compte
- Nom du cas d’utilisation : créer compte

- Objectif : permettre à l’utilisateur de se connecter au système.
- Acteur concerné : Utilisateur
- Précondition : avoir un compte E-mail
- Scenario nominal :
1. Demander le formulaire d’inscription
2. Afficher le formulaire d’inscription
3. Saisir les coordonnées
4. Valider
- Scénario alternatif :
4a. Si les coordonnées sont incomplètes le système réaffiche le formulaire d’inscription,
4b. Sinon passé au scénario 5.
- Post-condition : afficher page de menus
37
Système
: Participant
1 : Demander formulaire d'inscription
2 : Affichage formulaire d'inscription
3 : Saisir coordonnées
4 : Valider
alt
5 [si coord incomplet] : Message d'erreur
6 [sinon] : affichage page de menus
Figure 9: Diagramme de séquence système Créer compte
- Nom du cas d’utilisation : Authentification

- Objet : permettre la sécurité de comptes des utilisateurs.
- Précondition : avoir un compte E-mail et avoir s’inscrire au système.
1. Saisir Email
2. Saisir Mot de passe
3. Valider
4. Afficher la page d’accueil.
- Scénario alternatif :
3a. si les coordonnées sont incomplètes ou incorrectes, le système d’envoi un message et
demande à l’utilisateur de ressaisir l’Email ou le Mot de passe sinon passé au scénario 4.
- Post-condition : afficher la page de menus.
38
Système
: Utilisateur
1 : Saisir Email
2 : Saisir Mot de passe
3 : Valider()
alt
4 [MP Incorrect] : : Message d'erreur
5 [sinon] : : Affichage page Menus
Figure 10: Diagramme de séquence système Authentification
- Nom du cas d’utilisateur : Chatter

- Objectif : permettre de communiquer avec différents participants qui s’affichent sur la liste
sous message texte.
- Précondition : être connecté au système et participer dans une réunion.
1. Demander page chatte
2. Affichage page chatte
3. Choisir un participant ou tout le monde pour chatter
4. Saisir le message
5. Envoyer
6. Affichage page Menus
- Scénario alternatif : Néant
- Post-condition : page de menus
39
Système
: Participant
1 : Demander page chatte
2 : Affichage page chatte

3 : Choisir un participant ou un groupe de participants
4 : Saisir Message
5 : Envoyer
Figure 11: Diagramme de séquence système Chatter
- Nom du cas d’utilisation : Supprimer participant

- Objectif : l’objet de ce cas d’utilisation est de diminuer le nombre des participants dans une
réunion et rester avec les concernés.
- Acteur : Administrateur
- Précondition : être connecté au système et avoir le droit d’organisateur de la réunion.
- Scénario-nominal :
1. Demander le formulaire de la réunion
2. Affichage formulaire de la réunion
3. Lister status participant
4. Afficher status participant
5. Supprimer un ou plusieurs participants
- Scénario-alternatif : néant
- Post-condition : afficher la page de menus.
40
Système
: Administrateur
1 : Demander formulaire réunion
2 : Affichage formulaire
3 : Lister status participant
4 : Affichage Liste participant
5 : Supprimer participant
Figure 12: Diagramme de séquence système Supprimer participant
C. ETUDE DES SUPPORTS D’ECHANGES INFORMATIONNELS
II.5.1. ETUDE DES DOCUMENTS
- Registre de lettres : permet d’enregistrer les différentes informations sur les lettres
expédiées et envoyées. Il contient les informations suivantes :
1. Numéro de référence
2. Objet de la lettre
3. Expéditeur
4. Date Edition
41
II.5.2. DIAGRAMME DE CLASSES DU DOMAINE
Le diagramme de classe permet de donner la représentation statique du système à

développer. Cette représentation est centrée sur les concepts de classe et d’association.29
Une classe permet de décrire un ensemble d’objets (attributs et comportement),

tandis qu’une relation ou association permet de faire apparaître des liens entre ces objets.30
Le diagramme de classes est le point central dans un développement orienté objet.

En analyse, il a pour objectif de décrire la structure des entités manipulées par les utilisateurs. En
conception, le diagramme de classes représente la structure d’un code orienté objet ou, à un niveau
de détail le plus important, les modules du langage de développement.31
29
Joseph Gabay, David Gabay, Op.cit, p.14
30
DI GALLO Frédéric, Méthodologies des systèmes d’information UML, CNAM ANGOULEME
2000-2001, p.42
31
Pascal Roques, Op.cit., p.76
42
Diagramme de classes du domaine
COMPTE
-Idcompte
-Email
-MotPasse
-Categorie
-Status
1..*
Posseder
1..*
CONFERENCE
PARTICIPANT
-Numero
-Id -Objet
-Nom Participer
-Organisateur
-PostNom 1..* 1..* -NombreParticipant
-Localisation -Durée
1 -Date
1
DATE
Envoyer Avoir 1
-DateEnvoi
-DateLecture Concerner
1..* 0..1
MESSAGE 1..* INVITATION
-Code -Id
-Objet -Status
-Contenu
Figure 13: Diagramme de classes du domaine

43
D. PRESENTATION DU DIAGNOSTIC DE L’EXISTANT

1. CRITIQUE DE L’EXISTANT
La critique est une phase très essentielle dans tout travail scientifique. Après un
diagnostic fait dans le système actuel, nous avons trouvé comme grande faiblesse:
- La perte du temps dans transmission des informations : il faut attendre que celui qui a reçu
l’information auprès de l’Evêque puisse aller à la bureautique faire la saisie, l’impression et
multiplier les copies pour transmettre les informations, tout cela a comme conséquence la perte de
temps.
- Manque de la confidentialité de l’information : étant donné que la région épiscopale
manque les agents dans le département de l’informatique, ses informations sont à la portée de tout
le monde, par conséquent les informations considérées secrètes seront diffusé par n’importe qui et
cela peut nuire à la région épiscopale.
2. PROPOSITION DE LA SOLUTION NOUVELLE
Pour remédier à ces problèmes nous proposons une application informatique de

vidéo-conférence au sein du Bureau Episcopal de la Région Episcopale du Nord-Katanga,
Tanganyika et Tanzanie.
44
CHAPITRE TROISIEME : CONCEPTION DETAILLEE DU

SYSTEME INFORMATIQUE
III.1. INTRODUCTION
La conception du système informatique permet d’acquérir une compréhension
approfondie des contraintes liées au langage de programmation, à l’utilisation des composants et
au système d’exploitation. Elle détermine les principales interfaces et les transcrits à l’aide d’une
notation commune.
Tout au long de ce chapitre, il sera question de faire une représentation de
l’architecture du système, de la solution informatique portant sur la conception des diagrammes
de séquence de conception, diagrammes des classes de conceptions ainsi que la construction du
modèle logique de données.
III.2. NOTION DU DIAGRAMME DE SEQUENCE CONCEPTION

Par rapport aux diagrammes de séquences système, nous remplaçons ici le système,
vu comme une boîte noire, par un ensemble d’objets en collaboration. Ces objets sont des instances
des trois types de classes d’analyse du diagramme de classes participantes, à savoir des dialogues
(Les classes qui permettent les interactions entre l’IHM et les utilisateurs), des contrôles (Les
classes qui modélisent la cinématique de l’application) et des entités (Les classes métier, qui
proviennent directement du modèle du domaine). Les diagrammes de séquences élaborés dans
cette section doivent donc toujours respecter les règles. Ces règles doivent cependant être
transposées car, pour que deux objets puis interagir directement, il faut que :
 les classes dont ils sont issus soient en association dans le diagramme de classes
participantes;
 l’interaction respecte la navigabilité de l’association en question.
45
1. Diagramme de séquence conception planifier réunion
Page planification Ctrl Planification Invitation

: Administrateur
5 : Envoyer programme
6 : Envoyer
7 : Envoyer()
8 : Insert
9 : Resultat
10 : Resultat
Figure 14: Diagramme de séquence conception Planifier réunion
2. Diagramme de séquence conception Gérer Réunion
Page Réunion Ctrl Réunion Conference Participant

: Administrateur
3 : Select
4 : Résultat
5 : Résultat
6 : Lister Participant
9 : Grant
10 : Résultat
11 : Résultat
Figure 15: Diagramme de séquence conception Gérer Réunion

46
3. Diagramme de séquence conception Ajouter Participant
Page Menus Page Participant Ctrl participant Participant

: Administrateur
3 : Show()
4 : Saisir informations
5 : Confirmer
6 : Confirmer
7 : Insert
8 : Résultat
9 : Résultat
10 : Affichage Page Menus
Figure 16: Diagramme de séquence conception Ajouter Participant
4. Diagramme de séquence conception Gérer compte
Page Menus Page Compte Ctrl Compte Compte

: Administrateur
3 : show()
4 : Rechercher compte user
5 : Rechercher
6 : Select
8 : Résultat 7 : Résultat
9 : Affichage du résultat
10 : Octroyer Droit
11 : Octroyer
12 : Grant
13 : Résultat
14 : Résultat
15 : Message de confirmation
Figure 17: Diagramme de séquence conception Gérer Réunion

47
5. Diagramme de séquence conception Créer compte
Page Menus Page Inscription Ctrl Inscription Compte

: Participant

3 : Show()
4 : Saisir coordonnées
5 : Valider
6 : Valider 7 : Insert
alt 9 : Message d'erreur 8 : Résultat

10 : Message d'erreur
11 : Résultat
12 : page de menus
13 : Affichage
Figure 18: Diagramme de séquence conception Créer Compte
6. Diagramme de séquence conception Authentification
Authentification Ctrl Authentification Compte

: Administrateur
1 : Saisir Email
2 : Saisir Mot de passe

3 : Valider
4 : Valider
5 : Select
alt 6 : Résultat
9 : Résultat
Figure 19: Diagramme de séquence conception Authentification

48
7. Diagramme de séquence conception chatter
Page de menus Page chatter Ctrl Chatter Message

: Utilisateur
3 : Affichage page chatte
4 : Choisir un participant ou un groupe de participants
5 : Saisir Message
6 : Envoyer Message
7 : Envoyer Message
8 : Envoyer
9 : Résultat
11 : Affichage Page de menus
Figure 20: Diagramme de séquence conception chatter

49
8. Diagramme de séquence conception Supprimer participant
Page Menus Page Réunion Ctrl Réunion Conférence

: Administrateur
3 : Select
4 : Résultat
5 : Affichage formulaire réunion
10 : Select
11 : Resultat
12 : Affichage liste
13 : Affichage Liste
14 : Affichage Liste
17 : Delete
18 : Résultat
Figure 21: Diagramme de séquence conception Supprimer Participant
III.3 NOTION DE DIAGRAMME DE CLASSES PARTICIPANTES

Le diagramme de classes participantes est particulièrement important puisqu’il
effectue la jonction entre, d’une part, les cas d’utilisation, le modèle du domaine et la maquette, et
d’autre part, les diagrammes de conception logicielle que sont les diagrammes d’interaction et le
diagramme de classes de conception.32
Lors de l’élaboration du diagramme de classes participantes, il faut veiller au respect des règles
suivantes :
- Les entités, qui sont issues du modèle du domaine, ne comportent que des attributs.
32
Laurent AUDIBERT, Op.cit., p.115
50
- Les entités ne peuvent être connectées (association) qu’avec d’autres entités ou avec des
contrôles mais, dans ce dernier cas, avec une contrainte de navigabilité interdisant de traverser une
association d’une entité vers un contrôle.
- Les contrôles ne comportent que des opérations. Ils implémentent la logique applicative,
et peuvent correspondre à des règles transverses à plusieurs entités. Chaque contrôle est
généralement associé à un cas d’utilisation, et vice versa. Mais rien n’empêche de décomposer un
cas d’utilisation complexe en plusieurs contrôles.
- Les contrôles peuvent être associés à tous les types de classes, y compris d’autres contrôles.
Dans le cas d’une association entre un dialogue et un contrôle, une contrainte de navigabilité doit
interdire de traverser l’association du contrôle vers le dialogue.
- Les dialogues comportent des attributs et des opérations. Les attributs représentent des
informations ou des paramètres saisis par l’utilisateur ou des résultats d’actions. Les opérations
réalisent (généralement par délégation aux contrôles) les actions que l’utilisateur demande par le
biais de l’IHM.
- Les dialogues peuvent être en association avec des contrôles ou d’autres dialogues, mais
pas directement avec des entités.
Il est également possible d’ajouter les acteurs sur le diagramme de classes participantes en
respectant la règle suivante : un acteur ne peut être lié qu’à un dialogue.
51
1. Diagramme de classes participantes Planifier réunion
Invitation
-IdInvitation
Planifier réunion -Status
Ctrl Planification
-Numero
-Objet +Envoyer()
-Email +Accepter()
+Durée +Refuser()
-Message +Recevoir() Participant
+Envoyer() -Id
+Annuler() -Nom
-PostNom
-Localisation
Figure 22: Diagramme de classes participantes Planifier réunion
2. Diagramme de classes participantes Gérer Réunion
Page de menus Conférence

-Menus -Numéro
-Objet
+AfficherPage() -Organisateur
Ctrl Réunion -NbreParticipant
-Durée
+AfficherPage() -Date
Page Conférence +Demarrer()
-Objet +Rejoindre()
-Organisateur +Quitter()
-NbreParticipant Participant
+Durée
-Id
-Date
-Nom
+Demarrer() -PostNom
+Rejoindre() -Localisation
+Quitter()
Figure 23: Diagramme de classes participantes Gérer Réunion

52
3. Diagramme de classes participantes Ajouter participant
Page de menus
-Menus
+AfficherPage()
Participant
Ctrl Participant
-Id
+AfficherPage() -Nom
Participant +Ajouter() -PostNom
+Supprimer() -Localisation
-Id
-Nom +Ajouter()
-PostNom +Supprimer()
-Localisation
+Ajouter()
+Supprimer()
Figure 24: Diagramme de classes participantes Ajouter Participant
4. Diagramme de classes participantes Gérer compte
Page Menus
-Menus
+AfficherPage() Ctrl compte Compte
-IdCompte
+AfficherPage() -Email
+Créer() -MotPasse
+Supprimer() -Categorie
Page compte +Modifier() -Status
-Nom
-PostNom
-Localisation
+Créer()
+Supprimer()
+Modifier()
Figure 25: Diagramme de classes participantes Gérer Compte

53
5. Diagramme de classes participantes Créer Compte
Page Menus
-Menus
Ctrl compte
+AfficherPage() Compte
+AfficherPage()
+Créer() -IdCompte
+Supprimer() -Email
Page compte +Modifier() -MotPasse
-Nom -Categorie
-PostNom -Status
-Localisation
+Créer()
+Supprimer()
+Modifier()
Figure 26: Diagramme de classes participantes Créer Compte
6. Diagramme de classes participantes Authentification
Compte
Page Authentification -IdCompte
-Email Ctrl Authentification
-Email
-MotPasse +Connexion() -MotPasse
+Connexion() +Annuler() -Categorie
+Annuler() -Status
Figure 27: Diagramme de classes participantes Authentification

54
7. Diagramme de classes participantes Chatter
Page Menus Message

-Menus -Code
+AfficherPage() -Objet
Ctrl Chatte -Contenu
+AfficherPage()
Page de chatte +Envoyer()
+Recevoir()
-Email +Supprimer() participant
-Objet -Id
-Contenu -Nom
+Envoyer() -PostNom
+Recevoir() -Localisation
+Supprimer()
Figure 28: Diagramme de classes participantes Chatter
8. Diagramme de classes participantes supprimer participant
Page Menus Conférence

-Menus -Numero
-Objet
+AfficherPage()
-Organisateur
Ctrl Conférence -NbreParticipant
-Durée
Page conférence +AfficherPage() -Date
-Objet +Rechercher()
-Organisateur +Supprimer()
-NbreParticipant participant
-Durée -Id
-Date -Nom
+Rechercher() -PostNom
+Supprimer() -Localisation
Figure 29: Diagramme de classes participantes Supprimer Participant

55
III.4. DIAGRAMME DE CLASSES CONCEPTION
COMPTE
-Idcompte
-Email
-MotPasse
-Categorie
-Status
+Créer()
+Supprimer()
+modifier()
1..*
Posseder CONFERENCE
1..* -Numero
PARTICIPANT -Objet
-Organisateur
-Id -NombreParticipant
-Nom Participer -Durée
-PostNom 1..* -Date
-Localisation 1..*
+Demarrer()
DATE +Ajouter() +Quitter()
+Supprimer() 1 +Rejoindre()
-DateEnvoi
-DateLecture
1 Avoir
Envoyer 1
Concerner
0..1
INVITATION
1..*
-Id
MESSAGE 1..* -Status
-Code +Envoyer()
-Objet +Recevoir()
-Contenu +Accepter()
+Envoyer() +Refuser()
+Recevoir()
+Supprimer()
Figure 30: Diagramme de classes conception

56
CHAPITRE QUATRIEME : ARCHITECTURE TECHNIQUE ET

IMPLEMENTATION
0. INTRODCUTION
L’architecture désigne la structure générale inhérente à un système informatique,

l’organisation des différents éléments du système (logiciels et/ou matériels et/ou humains et/ou
informations) et des relations entre ces éléments. Cette structure fait suite à un ensemble de
décisions stratégiques prises durant la conception de tout ou partie du système informatique, par
l’exercice d’une discipline technique et industrielle du secteur informatique dénommée aussi
architecture, et dont le responsable est l’architecte informatique.33
L’architecture technique est vue tournée vers les différents éléments matériels et
l’infrastructure dans laquelle le système informatique s’inscrit, les liaisons physiques et logiques
entre ces éléments et les informations qui y circulent.
La vue contient le matériel informatique, les logiciels systèmes, les middlewares

(ou interagi ciel en français, est un logiciel tiers qui crée un réseau d’échange d’informations entre
différentes applications informatiques), ainsi que les réseaux de télécommunications et les
relations entre ces différents éléments.
I. CHOIX DE TECHNOLOGIES
A. Plateforme de développement
Le Cisco webex meetings server est une solution de conférence entièrement

virtualisée qui est centralisée sur un réseau. Il combine les conférences audio et web dans une seule
solution. Le Cisco webex Meeting a été commercialisée pour les environnements de cloud privés
et offre, contrairement aux offres de cloud computing publiques, la possibilité d’exploiter tous les
outils nécessaires pour tenir des réunions en ligne performantes dans votre propre centre de
données. La variante de cloud privé offre la même utilisation que les clouds webex publics,
33
http://www.wikipedia.com/architecture_informatique, 01/07/2019 à 09h30’
57
notamment avec des clients pc, Mac, Iphone et Ipad ainsi que des vidéos HD, des fonctions de
partage, d’annotations, d’enregistrement de conversation et de lecture.
En effet Cisco WebexMeeting une société américaine offrant des services logiciels
de vidéoconférence et de web conférence à la demande. En 2015, elle est détenue par Cisco. Elle
commercialise notamment Meeting center, training center, Event Center, WebexOffice et
WebexConnect. Webex a été fondé en 1996 par Subrah Iyar et Min Zhu. En 2005, cisco a déclaré
son intention de l’acquérir pour 3.2millards USD. Le rachat est effectif début 2007.
Par extension, le terme « webex » désigne le web conférence elle-même. Pour

optimiser la quantité de bande passante utilisée, le principe est de ne transférer que les parties
modifiés des images écran, et c’est avec un protocole propriétaire de compression de données
appelé UCF (Universal Communication Format) qui traite les formats de données audio, vidéo,
PowerPoint, QuickTime et adobeFlash. Le cisco webex meeting donne la possibilité d’organisez
ou de rejoindre une réunion à l’aide d’un navigateur web, d’un téléphone mobile ou d’une tablette.
Donnez aux participants la possibilité de se connecter par téléphone ou en audio intégré sur
l’ordinateur, quel que soit leur emplacement. Les solutions de collaboration cisco webex
permettent de minimiser les coûts et d’optimiser les ressources IT.
Les solutions de web conférences webex sont livrées comme software-as-a-service

(SaaS) par le biais du cisco collaboration cloud. Le cisco collaboration cloud est un réseau mondial
conçu spécifiquement pour un service hautement sécurisé des applications à la demande. Il offre
une architecture évolutive, une disponibilité constante et une sécurité multicouche validée.
B. Moyen de sauvegarde de données
Dans ce travail, nous avons choisi d’utiliser le système de gestion de base de données
PostgreSQL.
PostgreSQL est un système de gestion de base de données relationnelle et objet sortie

le 29 janvier 1997. C’est un outil libre disponible selon les termes d’une licence de type BSD. C’est la
plus connue des bases de données Open Source. Elle est développée par la société MySQL AB. Il été
développé par Michael Stonebraker qui publia sa première version en 1995.
58
II. ARCHITECTURE DE DEPLOIEMENT

1. 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.34
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.
Les diagrammes de déploiement peuvent montrer des instances de nœuds (un matériel
précis), ou des classes de nœuds.
Les diagrammes de déploiement correspondent à la vue de déploiement d'une architecture
logicielle.
Figure 31: Diagramme de deploiement
34
http://uml@free.fr/index-me.html, le 09/07/2019 à 15h10
59
III. IMPLEMENTATION
III.1. Présentation des classes de dialogues
Page d’authentification
Cette page permet à l’utilisateur de rentrer son compte Email afin de se connecter
au système (application) webex.
Page de menus
60
Page Programmer Réunion

Cette page permet de programmer une réunion afin que chaque participant sois informé de la
réunion.
Page de réunion
61
CONCLUSION GENERALE
Tout est bien qui finit bien, pareil à ce travail de fin d’études, qui se focalise sur la
mise place d’une application informatique de vidéo-conférence au sein de la Région Episcopale
du Nord-Katanga, Tanganyika et Tanzanie.
En effet, notre but est de mettre en place une application informatique qui va gérer
toutes réunions (conférences) au sein de ladite région en temps réel et peu importe l’emplacement
(endroit) des participants.
Hormis l’introduction et la conclusion, le travail rode autour de quatre chapitres

très importants :
- Le premier, Généralités, Il était question de définir tous les concepts du domaine,

informatique, le langage de programmation et la méthode utilisée tout au long de la recherche.
- Le deuxième, Présentation du champ d’étude et analyse de l’existant, consacré à l’étude de
l’organisation, en présentant son existant, il permet de situer géographiquement ladite organisation
et d’avoir une idée claire sur la structure organisationnelle de son fonctionnement. Ce dernier
analyse tout le métier, les déroulements des activités et permet d’appréhender deux points de vue,
la structure statique et comportementale. Il s’agit de deux perspectives différentes qui aident à
compléter la compréhension du système à développer.
- Le troisième, conception détaillé du système informatique, il était question d’acquérir une
compréhension approfondie des contraintes liées au langage de programmation, à l’utilisation des
composants et au système d’exploitation. Elle détermine les principales interfaces et les transcrits
à l’aide d’une notation commune.
- Le quatrième, l’architecture technique et implémentation, qui a donné une vue tournée vers
les différents éléments matériels et l’infrastructure dans laquelle le système informatique s’inscrit,
les liaisons physiques et logiques entre ces éléments et les informations qui y circulent.
Nous tenons à confirmer l’hypothèse formulait dans l’introduction de ce travail que

cela était vrai pour pallier au problème que rencontre la Région Episcopale du Nord-Katanga,
Tanganyika et Tanzanie.
62
Etant donné que nul ne peut se prétendre aborder un domaine dans son ensemble,
notre étude se veut-elle une référence et comme toute œuvre humaine est de nature imparfaite et
ne manque pas des imperfections, nous demandons aux chercheurs et lecteurs de ce modeste travail
que les remarques et critiques seront les bienvenues pour nous améliorer dans le prochain jour.
63
BIBLIOGRAPHIE
Ouvrages
1. A. MULUMBATI NGASHA, introduction à la science politique, 3e éd. AFRICA, 2010.

2. DI GALLO Frédéric, Méthodologie des systèmes d’informations – UML, CNAM
ANGOULEME 2000-2001.
3. GILLE ROY, Conception de base de données avec UML, presses de l’université de Québec,
2003.
4. GRAWITZ, Méthodes de sciences sociales, 5e édition, 1975.

5. Joseph Gabay, David Gabay, UML 2 Analyse et Conception, DUNOD, Paris, 2008.
8. Pascal Roques, Franck Vallée, UML 2 en action de l’analyse des besoins à la conception, éd.
Eyrolles, 4eme édition, 2007.
9. P. roques, UML 2.0 modéliser une application web, éd. Eyrolles, paris 2004.
10. Xavier Blanc, Isabelle Mounier, UML 2 pour les développeurs, éd. Eyrolles.
Dictionnaires
1. Dictionnaire français, Larousse illustré, éd. Maury-Manche court, 2010.

2. Dictionnaire français, Larousse Illustré, éd. Manche-Court, 2010.
3. Copyright (©) Larousse 2009
4. Copyright (©) jargon informatique
SITE WEB
1. http://uml@free.fr/index-me.html
2. http://www.wikepedia.com

Voir Ses Collègues Et Être Vu Soi-Même Est Essentiel Pour Un Travail D'équipe Constructif Et Efficace

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Voir Ses Collègues Et Être Vu Soi-Même Est Essentiel Pour Un Travail D'équipe Constructif Et Efficace

Transféré par

Droits d'auteur :

Formats disponibles

I

A ma très chère famille MBUYI.

KATUMBA KALABELA Patient

A l’Église Méthodiste Unie, d’avoir mis à la disposition de l’humanité l’Université

A Monsieur l’Assistant Valery KABONGO MPANGA Claude directeur de notre

A toutes nos très chères autorités Académiques et Administratives plus

A mon Pasteur Jean MUTOMBO pour son assistance spirituelle.

A mon Serviteur Erick BUKASA pour son assistance financière, morale et

A mes Assistants de la faculté, Ir GAYLAS MULENDA, Ir Trésor MWAMBA

A ma famille : MWADI Florance, MBELU Eulalie, MIDIKI Mireille, MUZEMBA

A la famille KITENGE MUKAYA pour leurs assistances et encouragements.

A mes très cher(es) amis et amies : Chadrack MBAYO, Ornelia TSHIBINGU,

A mes camarades : JOJO MIKOMBE, Ali, Olivier MUTAMBA, Elie KABAMBA,

Figure 1: Organigramme du Bureau Episcopal ............................................................................ 23

UMK : Université Méthodiste de Kamina

UML : Unified Modeling Language

R.O.I : Règlement d’ordre intérieur

SGBD : Système de Gestion de Base de Données

Table des matières

II.2.1.3. ORGANIGRAMME HIERARCHIQUE ...................................................................... 23

2. CHOIX ET INTERET DU SUJET

 Du point de vue social

Pour la région épiscopale, l’application informatique de vidéo-conférence sera un

 Du point de vue personnel

A la fin de la réalisation de ce travail, nous aurons une maitrise des connaissances

La problématique est définie comme étant un ensemble de questions qu’une science

GRAWITZ définit l’hypothèse de travail ou de recherche comme une

Pour remédier aux difficultés rencontrées ci-haut au sein de la région épiscopale

Quant à la perte du temps dans la transmission d’informations, notre application

Pour la confidentialité, notre application sera dotée d’un système permettant à

PINTO ET GRAWITZ, cités par Adrien MULUMBATI NGASHA ont défini le

Désigne l’ensemble des canons guidant le processus de production des

La démarche qui nous a permis de justifier l’objectif de notre recherche c’est la

b. Méthode d’analyse et Conception de Système d’information

Les méthodes de conception de systèmes d’information ont pour objectif de

Il existe plusieurs méthodes d'analyse et conception du système d’information (UP,

 La phase d’insertion (Lancement).

A l’intérieur de ces 4 phases, on mène différentes activités : expression des besoins,

Une technique est l’ensemble d’outils importants permettant au chercheur de

4.3.SOURCE DES DONNEES

Une source ou source d'information est l'origine d'une information. Le concept de

Notre travail se limite à la région Episcopale du Nord-Katanga, Tanganyika et

Hormis l’Introduction Générale et la Conclusion Générale notre travail est

 Le deuxième chapitre s’étale sur : « PRESENTATION DU CHAMP D’ETUDE ET

 Le troisième chapitre prend le thème : « CONCPTION DETAILLEE DU SYSTEME

CHAPITRE PREMIER : GENERALITES

I.2 DEFINITIONS DES CONCEPTS

Une application est un programme, ou un ensemble de programmes, destiné à aider

L’informatique est une science du traitement rationnel, notamment par des

La vidéo-conférence est un système visuel et auditif permettant de communiquer

e. Région-épiscopale: La Région Episcopale est une subdivision ecclésiastique constituée de

B. Définition des concepts du domaine informatique

 Théorie sur l’information

Est un élément conceptuel permettant le transfert, le stockage et le traitement de la

L’information est composée de deux mots :

 un sens qui dépend de chaque individu.

Les informations traitées par l'informatique sont de différentes natures ; des

Le système d’information (SI) est un ensemble organisé de ressources qui permet

Un système d’information se construit à partir de l’analyse des processus métier de

Le système d’information a une double finalité :

a. une finalité fonctionnelle :

Le SI est un outil de communication et de coordination entre les différents services

2. une finalité sociale :