|
Ministère de l'Enseignement Supérieur et
Universitaire
UNIVERSITE PROTESTANTE DE LUBUMBASHI
FACULTE DES SCIENCES INFORMATIQUES
Vérité et Liberté
ANALYSE ET CONCEPTION PAR LA METHODE 2TUP DES MICROS
SERVICES DE PUBLICATION DES OEUVRES SCIENTIFIQUES ENTRE LE MINISTERE NATIONAL
DE L'ESU ET LES ENTITES UNIVERSITAIRES EN RDC.
Présenter par KAYEMBE MUKENDI PATRICK
Mémoire de fin d'études présente et
défendu en vue de l'obtention du grade d'ingénieur en sciences
informatiques
Option : informatique de gestion/ Conception de
système d'information
Octobre 2022
Ministère de l'Enseignement Supérieur et
Universitaire
UNIVERSITE PROTESTANTE DE LUBUMBASHI
FACULTE DES SCIENCES INFORMATIQUES
Vérité et Liberté
ANALYSE ETCONCEPTION PAR LA METHODE 2TUP DES MICROS SERVICES DE
PUBLICATION DES OEUVRES SCIENTIFIQUES ENTRE LE MINISTERE NATIONAL DE L'ESU ET
LES ENTITES UNIVERSITAIRES EN RDC.
Présenter par : KAYEMBE MUKENDI PATRICK
Directeur : Prof Jean Marie KANDA
Co-directeur : Ass. Grace MUKOMA
ANNEE ACADEMIQUE 2021-2022EPIGRAPHE
« Se réveiller, c'est se mettre à la
recherche du monde »
Alain
RESUME
Le ministère de l'enseignement supérieur et
universitaire joue un très grand rôle dans la gestion des
entités universitaires en république démocratique du
Congo.
Ainsi la communication entre ministère et
entités universitairesa entrainé une complexité dans la
gestion des activités du service de la gestion des oeuvres scientifiques
et notifications ministérielle ainsi que la communication entre
entités universitaires n'est pas rassurée.
Pour mener à bien leurs missions, ces différents
services ministère del'esu, entités universitaires doivent avoir
un système informatique pour la gestion de leurs activités
quotidiennes.
Cela nous a conduits à proposer, dans le cadre de ce
mémoire de fin d'étude de licence, une application basée
sur les micro services pour la gestion des oeuvres scientifiques entre le
ministère et entités universitaires. Cette application permet la
communication des oeuvres scientifiques universitaires en RDC et permettre
aussi au ministère de pouvoir communiqué avec les entités
d'études universitaires sans se déplacer grâce à
notre système. Chaque institution est identifiée par un code.
L'application permet aussi aux contrôleurs d'accès d'une
institution X d'avoir un système de contrôle d'accès qui
leurs permettra d'échangé avec une institution Y.
Pour une bonne gestion de ce projet, nous avons opté
pour la méthode (ou processus) unifiée 2TUP. Toujours dans le
cadre du projet, nous avons utilisé l'architecture micro service. Pour
l'implémentation nous avons utilisé leFrameworkJakarta. Nous
avons utilisé le Système de Gestion de Bases de Données
Relationnelles (SGBDR) MySQL pour le stockage des données et un serveur
d'application wildfly.
Mots clés : architecture micro service, oeuvres
scientifiques, ministère de l'esu et entités universitaires.
DEDICACE
A Ma très chèregrande université
protestante de Lubumbashi de m'avoir donné l'éducation,
l'affection, son effort consentis, et moyens misent en ma disposition pour que
j'arrive jusqu'ici, ce mémoire est le résultat de votre sens des
responsabilités et d'amour en mon égard.
KAYEMBE MUKENDI Patrick
REMERCIEMENT
Avant la présentation de ce compte rendu, nous
remercions premièrement notre Dieu le créateur qui a fait
à ce que par sa grâce nous soyons vivants et en bonne
santé, en nous accordant le souffle de vie et à mon Pasteur.
Nos remerciements s'adressent également à tout
le corps professoral de l'UPL et en particulier les enseignants de la
faculté des sciences informatiques chapeauté par le doyen Daniel
KATUAL qui, par leurs savoir-faire et du savoir être nous ont
assuré un encadrement favorable.
Nos remerciements les plus sincères s'adresse
également à l'endroit du professeur jean marie KANDA, qui en
dépit ses multiplets préoccupations n'a pas hésité
d'accepter la direction de ce travail scientifique ; ses conseils et ses
remarques nous étaient fort appréciables dans
l'élaboration de ce travail scientifique.
Nous ne pouvons oublier de dire un mot également
à notre codirecteur, assistant grâce MUKOMA pour ses orientations
au tout long de la rédaction de notre travail.
Nos remerciements s'adressent aussi à la grande famille
MUKENDI pour ses encouragements et soutien, de loin ou de près vous avez
était une source de réconfort.
Nos remerciements s'adressent particulièrement à
ma soeur MUADI jeannette pour son soutien indéfectible tout au long de
mon parcours académique.
Nous disons aussi merci à nos ami(e)s et de
manière particulière MAUWA MWAMBA Ornelly, MBUYA NGOMBE
Joyce, NKUNDA MADANI Gabriel, KALALA Michée et MPIANA Jonathan pour tous
vos soutien physique et morale je vous dis merci du fond de mon coeur.
Nos sentiments de gratitude s'adressent également
à tous nos compagnons de lutte avec qui, nous avons partagés de
grands moments inoubliables.
A ce sujet, qu'il nous soit permis d'adresser les
remerciements les plus sincères à toutes les personnes qui ont
d'une manière ou d'une autre contribue à l'élaboration de
ce travail ainsi qu'à la conquête du monde scientifique, en
particulier nous citons INFO BULLE.
Ne pouvant pas tous citer, je vous remercie et vous jetant
à chacun et chacune un bouquet de fleur qui ne fanera jamais.
KAYEMBE MUKENDI Patrick
LISTES DES FIGURES
Figure 1 : Découpage d'une application en
petits services
1
Figure 2: identifications des acteurs
17
Figure 3: le diagramme de contexte dynamique
17
Figure 4 diagramme de cas d'utilisation
métier
19
Figure 5-le diagramme de cas d'utilisation gestion
notification
26
Figure 6-le diagramme de cas d'utilisation gestion
oeuvre scientifique
26
Figure 7- le diagramme de cas d'utilisation gestion
utilisateurs
27
Figure 8- le diagramme de séquence
s'authentifier
33
Figure 9- le diagramme de séquence
gérer institutions
35
Figure 10- le diagramme de séquence
gérer notifications
35
Figure 11- le diagramme de séquence
gérer oeuvres
36
Figure 12- le diagramme de séquence demander
renseignements
37
Figure 13- le diagramme de séquence
autoriser notification
38
Figure 14- le diagramme de séquence publier
oeuvre
39
Figure 15-le diagramme de séquence consulter
notification
40
Figure 16: le schéma de navigation
41
Figure 17- le diagramme de séquence
technique GI
42
Figure 18-le diagramme de séquence technique
GN
43
Figure 19- le diagramme de séquence
technique GO
44
Figure 20- le diagramme de séquence
technique DR
45
Figure 21- le diagramme de séquence
technique AUTN
46
Figure 22- le diagramme de séquence
technique PO
47
Figure 23- le diagramme de séquence
technique CU
48
Figure 24- le diagramme de classe technique CU
GI
49
Figure 25- le diagramme de classe technique CU
GN
50
Figure 26- le diagramme de classe technique CU
GO
51
Figure 27- le diagramme de classe CU DR
52
Figure 28- le diagramme de classe CU P
53
Figure 29- le diagramme de classe CU AUT
54
Figure 30- le diagramme de classe technique CU
UTI
55
Figure 31-le diagramme de classe
récapitulatif pour le package gestion institutions
56
Figure 32- le diagramme de classe
récapitulatif le package gestion notification
57
Figure 33-le diagramme de classe
récapitulatif gestion oeuvres sc.
58
Figure 34- Le diagramme de package
système
60
Figure 35- le diagramme de composant
61
Figure 36- Le diagramme de déploiement
SDGU
62
Figure 37- modèle logique de données
gestions institutions
64
Figure 38-le modèle logique de
données gestions notifications
64
Figure 39-modele logique de données gestions
oeuvres
65
Figure 40- base de données gestions
institutions
65
Figure 41- base de données gestions
notifications
66
Figure 42- base de données gestions
oeuvres
66
Figure 43- code SQL gestions institutions
67
Figure 44- le code SQL Gestions notifications
68
Figure 45- code SQL gestions oeuvres
69
Figure 46-Interface utilisateur gestions
universitaires
70
Figure 47- Interface utilisateur gestions
notifications
70
Figure 48- Interface utilisateur gestions oeuvres
scientifiques
71
Figure 49-Interface utilisateur s'authentifier
71
Figure 50- maquette de déploiement
72
LISTES DES ABREVIATIONS
-SDGU :Système de
Gestions Universitaires
-ESU :Enseignement
Supérieur et Universitaire
-HTML :HyperText
Markup Language
-CSS: Cascading Style
Sheets
-MYSQL: My Structured
Query Language
-API :Application
Programming Interface.
-MVC :Modèle Vue
Contrôleur
-SQL : Structured Query
Language
-SGDBR : Système de
Gestions Base des
données Relationnelles
-UP :Unified Process
-DN : Dirigeant national
-DA : Dirigeant
académique
-2TUP: Two Track
Unified Process
-UML: Unified Modeling
Language
-PHP: Hypertext Preprocessor
-HTTP: Hypertext Transfer
Protocol
-TCP: Transmission Control
Protocol
INTRODUCTION GENERALE
L'informatique connait une avancée technologique
considérable dans tous les secteurs d'activité. Elle y est
présente et est indispensable pour leur bon fonctionnement. En effet,
elle facilite le travail du personnel, assure la rapidité et
l'efficacité des taches.
Les technologies de l'information et de la communication
offrent la possibilité d'accéder à des masses
d'information de plus en plus grandes sur des supports de plus en plus
variés et supportant des modes d'interaction de plus en plus
différents. Un utilisateur peut rechercher et/ou recevoir de
l'information sur son ordinateur de bureau, son PDA, son
téléphone portable, etc. La plupart de ces plates-formes
d'accueil permettent une interaction multimodale combinant le son, l'image et
le texte.[1]
La prise en compte des modes d'interaction et des
plates-formes utilisées signifie, pour nous, Les Architectures Micro
Services (AMS) sont de plus en plus utilisées dans le
développement des applications, surtout depuis l'émergence du
Cloud computing et du Fog computing. Ce paradigme est une approche relativement
récente consistant à développera une application
distribuée en tant que suite de composants modulaires et autonomes,
appelés micro services. Chaque micro service est responsable d'une seule
fonctionnalité et peut être réutilise dans le cadre de
n'importe quelle application puisqu'il s'exécute dans son propre
processus et gère sa propre base de données. Grace à ces
caractéristiques, l'AMS est devenue aujourd'hui l'architecture
idéale pour les applications ou l''évolutivité, la
résilience et la disponibilité sont requises, comme c'est le cas
pour Netflix, Amazon, EBay et récemment, les applications de l'Internet
of Things.[2]
2TUP (Two Track Unified Process) représentative des
méthodes d'analyse et de conception orientées objet. Cette
méthode a été choisie parmi d'autres bien connues comme
RUP (Rational Unified Process) ou AUP (Agile Unified Process) par son processus
de développement qui distingue les aspects fonctionnels des aspects
techniques. En effet, ce principe rejoint celui que nous proposerons d'utiliser
dans le développement de système de données entre les
entités universitaires et le ministère de l'esu.
L'objectif de notre travail est de concevoir une architecture
micros services par la méthode 2TUP, grâce à
l'indépendance de l'Architecture micros services qui nous permettra
à ce que chaque composant (institution universitaire) soit
indépendante de l'autre mais en mesure de rechercher et recevoir les
informations d'une autre institution de la RDC. Cette architecture nous
permettra aussi de développer notre projet avec un Framework.
Notre sujet s'intitule analyse, conception et
développement par la méthode 2TUP d'une architecture micros
services de publications des oeuvres scientifiques entre le ministère
national de l'esu et les entités d'études universitaires en RDC.
Notre choix est porté sur cette thématique, par
ses interrogations sans réponses auprès des autorités,
alors que nous pensons y apporter une piste de solution par écrit et
pratique afin de participer à l'évolution et développement
de la RDC.
Ce projet nous aidera à mieux appliquer les
théories étudiées durant notre formation universitaire, il
permettra également au ministère national de l'esu de mieux
gérer toutes les entités d'études universitaires sans
fournir beaucoup d'effort, et d'avoir une statistique correcte sur ceux-ci et
il est de nature à permettre aux futures chercheurs de s'y ressourcer
dans la rédaction des travaux.
Loin sans faux l'idée de prétendre être le
premier à pouvoir aborder ce domaine ; bon nombre de chercheurs ont bien
avant nous, parlé de cette thématique comme :
· SOME Iyo Ibso Maxence : Gestion intégrée
des communautés religieuses et des établissements des
Frères des Ecoles Chrétiennes du Burkina/Niger, mémoire
01/2011, UNIVERSITE POLYTECHNIQUE DE BOBO-DIOULASSO. Son objectif était
d'informatiser le système de gestion des ressources humaines
congrégation religieuse des Frères des Ecoles Chrétiennes
d'Afrique de l'Ouest.
· M. Babacar DIAGO : Automatisation du système de
restauration de l'Université Assane Seck de Ziguinchor, de la vente des
tickets au contrôle des accès aux restaurants, mémoire de
master 04/02/2022, Université Assane Seck de Ziguinchor UFR Sciences et
Technologies, son objectif était de dématérialiser les
tickets de restauration et permettre aux étudiants de pouvoir
acheté des tickets sans se déplacer grâce à la porte
money Univ-Money.
La particularité de notre travail se trouve au point
abordé dans leur travail, SOME aborde les problèmes liés
à la communauté religieuse et DIAGO aborde à son tour les
problèmes au sein d'une université avec ses différents
services et nous, nous avons comme objectif de concevoir une plateforme qui
permettra au ministère de l'esu de gérer les entités
universitaires et de faciliter la communication des universités entre
elle.
Le ministère de l'esu rencontre beaucoup de
difficultés pour la gestion des entités universitaires et de les
faire communiqué entre elle. Problèmes liés aux
correspondances administratives, retard d'acheminement d'informations des
entités, de stockage des données. C'est pourquoi nous nous somme
poser deux questions à savoir :
ü Quelle architecture logicielle serait adaptée
pour la publication des oeuvres scientifiques entre le ministère de
l'esu et les entités universitaires ?
ü Quelle démarche utilisée pour y
arrivé ?
Comme hypothèse, nous pouvons répondre
partiellement aux questions : concernant la 1ere question, l'architecture
logicielle adaptée la réalisation du projet est les micros
services qui nous permettra à ce que chaque entité soit
indépendante de l'autre et qui peut rechercher et recevoir les
informations d'une autre entité universitaire.
Quant à la deuxième question, la démarche
utilisée pour la conception est 2TUP puisqu'il propose un cycle de
développement en Y, qui dissocie les aspects techniques des aspects
fonctionnels. Il commence par une étude préliminaire qui consiste
essentiellement à identifier les acteurs qui vont interagir avec le
système à construire, les messages qu'échangent les
acteurs et le système, à produire le cahier des charges et
à modéliser le contexte (le système est une boîte
noire, les acteurs l'entourent et sont reliés à lui, sur l'axe
qui lie un acteur au système on met les messages que les deux
s'échangent avec le sens)[3].
La technique de modélisation nous permettra de
concevoir et développer notre système d'information pour son
effectivité.
Hormis l'introduction et la conclusion, notre travail est
subdivisé en 4 chapitres qui suit :
Le 1ere chapitre : Etat de l'art sur les micros
services et méthode 2TUP, dans ce chapitre, nous allons aborderons
les concepts généraux, les notions de micros services ainsi que
la méthodologie de l'utilisation.
Le 2em chapitre : Analyse du système
existant, dans ce chapitre,nous allons traiter le processus métier
du ministère national de l'esu en ressortissant les points faibles,
forts et proposer une solution. Nous allons également toucher de
recensements des besoins du système existant.
3em chapitre : Conception du SDGU, dans ce
chapitre, nous exposerons les exigences fonctionnelles du nouveau
système. Nous allons aussi analyser les exigences et concevoir un
nouveau système.
4em chapitre : Implémentation du
système SDGU, dans ce chapitre, nous exposerons le
fonctionnement(déploiement) en précisant l'environnement
d'exécution du système.
CHAPITRE I : ETAT DE L'ART SUR
LES MICROS SERVICES ET METHODE 2TUP
I.1. Introduction
Ce premier chapitre porte sur les concepts
généraux du sujet. Il aborde également la méthode
de conduite 2TUP ainsi que le langage de modélisation UML.
SECTION 1 : CONCEPTS CLES
-Analyse : c'est une méthode systémique qui
s'appuie sur la théorie des systèmes en vue d'une approche
systémique et globale d'un système d'information d'une
organisation. En génie logiciel, c'est l'ensemble des méthodes,
techniques et outils de production et maintenance de composants logiciel de
qualité.
-Conception : est une phase de cycle de vie d'un
logiciel, un ensemble d'activités qui à partir d'une demande
d'informatisation d'un processus permettent la conception, l'écriture et
la mise au point d'un logiciel. En génie logiciel, concevoir un logiciel
revient à organiser son architecture qui vient après analyse des
exigences fonctionnels.
-Développement : consiste à concevoir et
maintenir le fonctionnement des logiciels. Cette activité recouvre les
étapes d'étude, de conception, de transformation, de mise au
point et de maintenance des logiciels.
-Les oeuvres scientifiques : dans certaines disciplines,
le plus souvent des sciences dures, une oeuvre généralement
écrite par un scientifique, un chercheur ou un professeur, ou parfois
par un non scientifique et qui intervient dans le processus de diffusion des
connaissances en traitant des sujets de différentes disciplines
scientifiques. Autrement dit, les articles scientifiques publiés par les
chercheurs dans les revues scientifiques.
I.1.1. Les micros services
Les micros services désignent à la fois une
architecture et une approche moderne du logiciel dans laquelle le code
d'application est livré en petits morceaux gérables,
indépendants les uns des autres.[1]
Figure 1 :
Découpage d'une application en petits services
L'architecture Micro services propose une solution en principe
simple : découper une application en petits services, appelés
Micro services, parfaitement autonomes qui exposent une API (Application
Programming Interface) que les autres Micro services pourront consommer alors
qu'une architecture monolithe est une application dont l'ensemble du code et
des fonctionnalités sont implémenté dans un seul
programme.
Leur petite échelle et leur isolement relatif peuvent
entraîner de nombreux avantages supplémentaires, tels que :
· Les micros services définissent des API qui
exposent leurs fonctionnalités à n'importe quel client. Les
clients pourraient même être d'autres applications.
· Pour communiquer entre eux, les micro services
d'une application utilisent le modèle de communication
requête-réponse. L'implémentation typique utilise des
appels API REST basés sur le protocole HTTP.
· Chaque micro service peut être
développé à l'aide d'un langage et d'un cadre de
programmation qui conviennent le mieux au problème que le micro service
est conçu pour résoudre.
· Chaque micro service peut utiliser sa propre base
de données.
· Chaque micro service est déployé
indépendamment, sans affecter les autres micros services de
l'application.
· Les micros services sont simples, ciblés et
indépendants. L'application est donc plus facile à entretenir.
· Les fonctionnalités de l'application sont
réparties entre plusieurs services. Si un micro service échoue,
la fonctionnalité offerte par les autres micro services continue
d'être disponible.
· Caractéristiques du micro service[2]
Fonctionnalité unique
? Un micro service doit réaliser une seule
fonctionnalité de l'application globale
(Une tache bien précise)
? Un micro service peut contenir toutes les couches
logicielles (IHM [ev frontEnd], middleware et base de données)
? Un micro service possède un contexte
d'exécution séparé des autres (exemple : Machine virtuelle
ou conteneur
Flexibilité technologie : Utiliser les bons langages et
Framework selon la Fonctionnalité à réaliser.Equipe de
développement réduite
? Chaque micro service à sa propre équipe de
développement
? L'équipe de développement orientée
fonctionnalité (spécialisée)=>développement
agile et rapide.
? Développeurs backend
? Développeurs web
? Administrateurs bases de données
Déploiement ciblé
? Evolution d'une certaine partie sans tout
redéployer
? Un seul livrable à partir d'un seul code source
? Moins de coordination entre équipe quand il y a un
seul déploiement
? Déploiement plus fréquent
? Moins de risque
? Plus rapide
? Faciliter les mises à jour : l'entreprise est capable
de faire évoluer son
Application de façon très fréquente et de
répondre rapidement aux nouvelles [3]
SECTION 2 : CADRE
METHODOLOGIQUE
I.2.1. Processus unifié
Le processus unifié est un processus de
développement logiciel itératif, centré sur
l'architecture, piloté par des cas d'utilisation et orienté vers
la diminution des risques. C'est un patron de processus pouvant être
adapté à une large classe de systèmes logiciels, à
différents domaines d'application, à différents types
d'entreprises, à différents niveaux de compétences et
à différentes tailles de l'entreprise.[4]
Un processus unifié se distingue par ses
caractéristiques suivantes :
? Itératif : le logiciel nécessite une
compréhension progressive du problème à travers des
raffinements successifs et permet de développer une solution effective
de façon incrémentale par des itérations multiples.
? Piloté par les risques : les causes majeures
d'échec d'un projet logiciel doivent être écartées
en priorité.
? Centré sur l'architecture : le choix de
l'architecture logicielle est effectué lors des premières phases
de développement du logiciel. La conception des composants du
système est basée sur ce choix.
? Conduit par les cas d'utilisation : le processus est
orienté par les besoins utilisateurs représentés par des
cas d'utilisation. Les activités de modélisation reposent sur
UML. Ce langage de modélisation couvre les aspects structurels et
dynamiques de l'architecture et de la conception des logiciels. Il facilite une
modélisation par composants en utilisant une approche orientée
objet.
Dans la communauté objet, il existe plusieurs
processus unifiés en vogue comme eXtreme Programming (XP) et Rational
Unified Process (RUP). Dans notre étude, on a choisi de travailler avec
le processus 2TUP ; parce qu'il couvre des projets de toute taille et il a pu
faire une large place dans le domaine de la technologie et les risques des
projets.[1]
I.2.2. Processus 2TUP
« 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.
Le 2TUP propose un cycle de développement en Y, qui
dissocie les aspects techniques des aspects fonctionnels. Il commence par une
étude préliminaire qui consiste essentiellement à
identifier les acteurs qui vont interagir avec le système à
construire, les messages qu'échangent les acteurs et le système,
à produire le cahier des charges et à modéliser le
contexte (le système est une boîte noire, les acteurs l'entourent
et sont reliés à lui, sur l'axe qui lie un acteur au
système on met les messages que les deux s'échangent avec le
sens).
Le processus s'articule ensuite autour de trois phases
essentielles :
? une branche technique ;
? une branche fonctionnelle ;
? une phase de réalisation.
La branche fonctionnelle comporte :
· la capture des besoins fonctionnels, qui produit un
modèle des besoins focalisé sur le métier des
utilisateurs. Cette capture des besoins permet d'éviter au plus
tôt le risque de produire un système inadapté aux
utilisateurs.
· l'analyse, qui consiste à étudier
précisément la spécification fonctionnelle de
manière à obtenir une idée de ce que va réaliser le
système en termes de métier. Les résultats de l'analyse ne
dépendent d'aucune technologie particulière.
La branche technique comporte :
· la capture des besoins techniques, qui recense
toutes les contraintes et les choix dimensionnant la conception du
système. Les outils et les matériels sélectionnés
ainsi que la prise en compte de contraintes d'intégration avec
l'existant conditionnent généralement cette capture ;
· la conception générique, qui
définit ensuite les composants nécessaires à la
construction de l'architecture technique. Cette conception est
complètement indépendante des aspects fonctionnels. Elle a pour
objectif d'uniformiser et de réutiliser les mêmes
mécanismes pour tout un système. L'architecture technique
construit le squelette du système informatique. L'importance de sa
réussite est telle qu'il est conseillé de réaliser un
prototype pour assurer sa validité.
La branche du milieu comporte :
· la conception préliminaire, qui
représente une étape délicate, car elleintègre le
modèle d'analyse dans l'architecture technique de manière
à tracerla cartographie des composants du système à
développer ;
· la conception détaillée, qui
étudie ensuite comment réaliser chaque composant ;
· l'étape de codage, qui produit ces
composants et teste au fur et à mesure les unités de code
réalisées ;
· l'étape de recette, qui consiste enfin
à valider les fonctions du système développé.
I.2.3. Choix de la
modélisation UML
Il est difficile d'envisager le processus 2TUP sans recourir
à UML comme support. Le recours à la modélisation est
depuis longtemps une pratique indispensable au développement, car un
modèle est prévu pour anticiper les résultats
dudéveloppement.
Un modèle est, en effet, une abstraction du
résultat, dont le but est de collecter ou d'estimer les informations
d'un système.
UML s'articule autour de 14 types de diagrammes
différents, chacun d'eux étant dédié à la
représentation des concepts particuliers d'un système logiciel.
Par ailleurs,UML modélise le système suivant deux modes de
représentation : l'un concerne la structure du système pris
« au repos », l'autre concerne sa dynamique de fonctionnement. Les
deux représentations sont nécessaires et complémentaires
pour schématiser la façon dont est composé le
système et comment ses composantes fonctionnent entre elles. Le mode de
représentation statique s'appuie sur les six diagrammes
ci-après.
· Le diagramme de classes : Sur la branche
fonctionnelle, ce diagramme est prévu pour développer la
structure des entités utilisées par les utilisateurs. En
conception, le diagramme de classes représente les modules du langage de
développement.
· le diagramme d'objets sert à illustrer des
structures de classes compliquées. Ce diagramme est utilisé en
analyse pour vérifier l'adéquation d'un diagramme de classes
à différents cas possibles.
· le diagramme de composants représente en
premier lieu les concepts connus de l'exploitant du système pour
installer et dépanner le système. Il s'agit dans ce cas de
déterminer la structure des composants d'exploitation que sont les
librairies dynamiques, les instances de bases de données, les
applications, etc. le diagramme de composants représente en second lieu
les concepts de configuration logicielle.
· le diagramme de déploiement correspond
à la fois à la structure du réseau informatique qui prend
en charge le système logiciel, et la façon dont les composants
d'exploitation y sont installés.
· le diagramme de paquetage regroupe les
hiérarchies de classes. Il permet d'exprimer la dépendance entre
paquetage et donne une vision de la structure du logiciel.
· le diagramme de structure composite qui
présente la structure d'une classe complexe. Il permet de mettre en
évidence les différentes parties d'une classe lors de
l'exécution. Le mode de représentation dynamique ou
comportemental s'appuie sur les sept diagrammes ci-après.
· le diagramme de cas d'utilisation représente
la structure des fonctionnalités nécessaires aux utilisateurs du
système. Il est utilisé dans les deux étapes de capture
des besoins fonctionnels et techniques.
· le diagramme d'états représente le
cycle de vie commun aux objets d'une même classe. Ce diagramme
complète la connaissance des classes en analyse et en conception.
· le diagramme d'activités représente
les règles d'enchaînement des activités dans le
système. Il permet de consolider la spécification d'un cas
d'utilisation.
· Le diagramme de séquence qui est une
représentation séquentielle du déroulement des traitements
et des interactions entre les éléments du système et de
ses acteurs. Il représente les échanges de messages dans le cadre
d'un fonctionnement particulier du système.
· Le diagramme de communication qui est une
représentation simplifiée d'un diagramme de séquence se
concentrant sur les échanges de messages entre les objets.
· Diagramme global d'interaction permet de
décrire les enchaînements possibles entre les scénarios
préalablement identifiés sous forme de diagrammes de
séquences. C'est une variante du diagramme d'activité.
· Diagramme de temps permet de décrire les
variations d'une donnée au cours du temps
N.B : le 14em diagramme c'est le diagramme de profil
ajouté en 2013.
I.5. Conclusion
En résumé, ce chapitre nous a permis de
définir le périmètre de notre sujet. Il a permis de fixer
de choisir la méthode et le langage de modélisation à
utiliser pour sa réalisation.
Dans le chapitre suivant, nous allons présenter une
étude d'analyse du système existant de notre
périmètre
CHAPITRE II : ANALYSE DU
SYSTEME EXISTANT
II.1 Introduction
Dans ce chapitre, nous allons aborder une étude
préalable de notre travail sur les éléments
ci-après : la présentation du champ empirique, la
présentation du domaine d'étude, la liste des acteurs, le cahier
des charges, le choix technique et le diagramme de contexte, explique le
processus métier utilisé actuellement au ministère
provincial de l'éducation, de recherche scientifique et de nouvelle
citoyenneté dans la province du haut Katanga.il expose aussi les
avantages, les inconvénients ainsi qu'une piste de solution à la
problématique.
SECTION 1 : ETUDE
PRELIMINAIRE
II.1.1. Présentation
générale ministère national de l'enseignement
supérieur et universitaire en RDC [5]
Le Ministère de l'Enseignement Supérieur et
Universitaire a les attributions suivantes :
- Organisation de l'enseignement supérieur et
universitaire ;
- Création et tutelle des établissements publics
d'enseignement supérieur et universitaires ;
- Reconnaissance et validation des diplômes
étrangers ;
- Agrément des établissements privés
d'enseignement supérieur et universitaire et homologation de leurs
diplômes ;
- Création, tutelle et gestion de services de
l'enseignement supérieur et universitaire fonctionnant à
l'étranger ;
- Suivi de la scolarité des étudiants et de la
carrière des enseignants ;
- Négociation, suivi et gestion des dossiers des bourses
d'études et des stages à l'étranger, en collaboration avec
le Ministère ayant la Coopération Internationale dans ses
attributions ;
- Contrôle de la scolarité et entérinement
des diplômes nationaux ;
- Promotion de la recherche fondamentale et appliquée ;
- Organisation, promotion et supervision des activités
culturelles, sportives et de loisirs au sein des établissements
d'enseignement supérieur et universitaire publics ou privés
agréés, en collaboration avec le Ministère ayant dans ses
attributions les Sports et Loisirs;
- Inventaire, suivi et gestion du patrimoine mobilier et
immobilier des établissements du secteur de l'enseignement
supérieur et universitaire ;
- Mobilisation des fonds extrabudgétaires.
II.1.2. Présentation du
domaine d'étude
La direction générale de l'enseignement
supérieur et universitaire en RDC(DESU) est un service chargé de
relation entre le ministère et les entités universitaires. Ce
service est mis en place pour l'échange d'informations afin de mieux
gérer le secteur universitaire.
Il est chargé d'appuyer les entités
universitaires de la RDC sur le plan administratif, social et
d'éducation, le ministère doit faciliter la communication entre
universités et les entités entre elle-même.
La relation se fait comme suit : le conseiller du
ministère écrit une lettre à une université,
l'envoi chez le ministre et il vérifie puis, corrige avant d'approuver
après la logistique se charge d'acheminer le courriel à la
destination, l'université répond de la même manière
L'inverse est faisable. Il existe plusieurs sortes de documents de
travail :
Ø Correspondance normale : lorsqu'un individu
(étudiant) écrit au ministère face une situation ;
Ø Correspondance de note informative : lorsqu'un
agent du ministère, une université s'expliquent sur les faits
auprès du ministre en fonction ;
Ø Correspondance de note technique : lorsqu'on
fait état de besoins au ministère national afin d'une appuie
financière ;
Ø Correspondance explicative : lorsqu'une
entité universitaire x demande les informations à une
entité universitaire y.
II.1.3. CAHIER DES CHARGES
II.1.3.1 Présentation du projet
Dans le cadre du développement d'un service web de ses
différents services et activités, le Ministère de l'ESU
nous demande une attention particulière face à son fonctionnement
comme il s'agit d'un projet à caractère national, pour la mise en
oeuvre d'une solution intégrée de gestion des entités
d'études universitaires (SDGU) en RDC.
L'approche retenue pour la réalisation de ce projet de
grande envergure, exige une solution cible qui soit performante,
standardisée au niveau national, touchant les différents niveaux
de gouvernance (établissements universitaires, oeuvres et services
centraux).
II.1.3.2 Objectif de notre projet
Après avoir identifié les difficultés
dans la procédure actuelle de gestion des entités d'études
universitaires sur la publication des oeuvres scientifiques et notifications,
notre solution consiste à concevoir et développer une
architecture micro services du système actuel qui corrigera les
manquements et les défaillances notées. En effet, il consiste
à la communication des oeuvres scientifiques universitaires en RDC et
permettre au ministère de pouvoir communiqué avec les
entités d'études universitaires sans se déplacer
grâce à notre système. Chaque institution est
identifiée par un code. L'application permettra aussi aux
contrôleurs d'accès d'une institution X d'avoir un système
de contrôle d'accès qui leurs permettra d'échangé
avec une institution Y.
Les objectifs majeurs de ce projet sont :
? la publication des oeuvres scientifiques ;
? la possibilité de notifications universitaires par le
ministère ;
? la gestion des entités d'études universitaires
par le ministère de l'ESU ;
? l'échange de données d'une université X
à une université Y en ligne.
Pour une meilleure réalisation du projet, nous avons
opté pour l'architecture micros services, qui devait aussi rendre les
systèmes d'information plus adaptables et plus agiles[3].
II.1.3.3Choix techniques de notre projet
Dans le souci de concevoir une application web, nous avons
choisi
L'utilisation JAKARTA EE est une spécification pour la
plateforme java d'oracle, destinée aux applications d'entreprise. Java
EE propose plusieurs avantages dont nous pouvons en citer quelques qui nous ont
poussé de porter le choix sur lui :
De permettre l'ajout des bibliothèques logicielles
réservées à des applications professionnelles. Le but
étant de faciliter le développement d'applications pour des
architectures distribuées.
JAKARTA : unFramework qui représente un ensemble
de composant (aussi appelés librairies) js autonomes qui peuvent
être utilisé dans des projets web privé ou open source. Un
puissant et robuste Framework java EE pour les applications web complexe.
L'utilisation du langage HTML pour la présentation des
pages web, CSS pour la mise en forme des pages web et JavaScript est un langage
de programmation des scripts.
L'utilisation de la java comme langage de programmation
orienté objet, de l'intelligence artificielle, big data et la
création des applications web dans des environnements très
divers
Pour développer notre application, plusieurs outils
sont disponibles et là plus d'entre elle sont gratuites et
indispensable.
Un éditeur de texte : nous avons opté pour
codeReady
Un navigateur web : qui nous permettra de tester et
manipuler notre application. Dans notre cas, nous avons choisi Google chrome et
Firefox comme deux navigateur web.
Pour que notre ordinateur puisse lire du PHP et se comporter
comme un serveur, nous avons besoin des programmes supplémentaires comme
apache, PHP et MySQL.
Apache : qui est un serveur web, son rôle est
chargé et délivrer les pages web à l'utilisateur. Apache
ne gèreque des pages web statiques(HTML), il faut donc le
compléter aussi avec d'autres programmes.
PHP : qui est un plug-in pour Apache qui le rend capable
de traiter des pages web dynamiques en PHP. En claire la combinaison d'Apache
et PHP permet à un ordinateur de lire les pages web en PHP.
MySQL : qui est un logiciel de gestion de base de
données, il permet d'enregistrer les données de manière
organisée. C'est un système de gestion de base de données
relationnelles(SGBDR) et il est disponible sur une double licence GPL et
propriétaire, il utilise le langage SQL pour l'accès aux
données.
Il existe un Packs tous près qui contient ces trois
éléments tous réunis, c'est Wamp server pour Windows, nous
avons choisi celui-ci car il offre l'avantage d'être en français
et a la possibilité d'être à jour
régulièrement[6].
II.1.4. Recueil des besoins
fonctionnels
L'objectif est de décrire à partir des besoins
fonctionnels, le comportement des utilisateurs interne. Nous avons
recensé les fonctionnalités suivantes :
ü Gérer oeuvres : cette fonctionnalité
permet la publication des oeuvres scientifiques par les entités
universitaires ;
ü Demander renseignements : cette
fonctionnalité permet les échanges des informations entre une
entité X et une entité Y dans le système ;
ü Gérer institution : cette
fonctionnalité permet la reconnaissance d'une entité
universitaire en RDC ;
ü Gérer notifications : cette
fonctionnalité permet au ministère de notifieraux entités
universitaires les informations nécessaires de la bonne
gouvernance ;
ü Gérer utilisateurs : cette
fonctionnalité permet à l'administrateur système
d'accorder le droit d'accès aux entités universitaires.
II.1.5. IDENTIFICATION DES ACTEURS
DU SYSTEME
II.1.5.1. Introduction
L'identification des acteurs est une étape importante
dans un projet de développement. Elle permet de mieux mesurer
l'influence de chacun des groupes d'acteurs sur l'action à mener.Ces
acteurs seront regroupés par la suite sous forme de rôles dont
chacun englobe un ensemble d'entités. Le regroupement sera
effectué en se basant sur les interactions.
II.1.5.2. Listes des acteurs
L'étude de la typologie des rôles a conduit
à la classification suivante :
· Le ministère de l'ESU : gestionnaires DN,
ministre
· Administrateur
· Les entités universitaires :gestionnaires
DA, enseignants, Etudiants
II.1.5.3. Recueil des besoins opérationnels
À partir de la description des fonctionnalités,
nous avons recensé les opérations ci-dessus sont les suivants :
· Création, modification, lister, fermeture,
· Rechercher, supprimer, modifier et ajouter des oeuvres
scientifiques.
· Consulter des notifications ministérielles,
rechercher suivant des critères précis.
· Créer, retirer, modifier et supprimer des
utilisateurs.
Figure 2:
identifications des acteurs
II.1.6. DIAGRAMME DE CONTEXTE
DYNAMIQUE
Le diagramme de contexte a pour but de représenter les
flux d'informations entre le système et les acteurs externes. Il permet
d'isoler le système en le délimitant et ainsi définir les
éléments externes avec lesquels il interagit.
Figure 3: le diagramme
de contexte dynamique
II.1.7. MODELE DE CONTEXTE
STATIQUE
A partir des informations obtenues lors des
précédentes étapes, une modélisation du contexte de
l'application est effectuée. Cela permet de définir le rôle
de chaque acteur à travers le tableau. Ce tableau définit les
utilisateurs et leur associe leurs besoins fonctionnels.
|
Utilisateurs
|
Description des besoins fonctionnels
|
|
Gestionnaire DN
|
L'application doit permettre au gestionnaire DN de :
· S'authentifier
· Publier des notifications ministérielles
· Créer/modifier une institution
· Fermer une institution
· Consulter une oeuvre
· Modifier une notification
|
|
Ministre
|
L'application doit permettre au ministre de :
· S'authentifier
· Consulter une institution
· Consulter une oeuvre
|
|
Gestionnaire DA
|
L'application doit permettre au gestionnaire DA de :
· S'authentifier
· Créer une oeuvre
· Publier un article
· Demander renseignements
|
|
Utilisateurs externe
|
L'application doit permettre aux utilisateurs de :
· S'authentifier
· Consulter une oeuvre
· Rechercher une oeuvre
· Consulter une notification
|
|
Administrateur
|
L'application doit permettre à l'Administrateur
système de :
· S'authentifier
· Créer les profils utilisateurs
· Donner des droits d'accès
· Configurer l'application
|
SECTION II : ANALYSE
METIER
II.2.1. Diagramme de cas
d'utilisation métier
À partir de la connaissance des besoins des acteurs,
nous élaborons une vision générale des cas d'utilisation
du système existant en produisant le DCU métier.
Figure 4 diagramme de cas
d'utilisation métier
II.2.2 DIAGRAMME D'ACTIVITE
Le diagramme d'activité représente la dynamique
du système. Il montre l'enchaînement des activités d'un
système ou même d'une opération. Le diagramme
d'activité représente le flot de contrôle qui retrace le
fil d'exécution et qui transite d'une activité à l'autre
dans le système.
Le diagramme d'activité se concentre sur des
activités, des gros morceaux du processus qui peuvent ou peuvent ne pas
correspondre aux méthodes ou aux fonctions de membre, et
l'ordonnancement de ces activités. Dans ce sens il est comme un
organigramme.
Figure 5 : diagramme d'activité
métier
II.2.3. DIAGRAMME DE CLASSE
METIER
Une classe décrit un groupe d'objets ayant les
mêmes propriétés (attributs), un même comportement
(opérations), et une sémantique commune (domaine de
définition). Un objet est une instance d'une classe. La classe
représente l'abstraction de ses objets. Au niveau de
l'implémentation, c'est-à-dire au cours de l'exécution
d'un programme, l'identificateur d'un objet correspond une adresse
mémoire.
Une classe se représente à l'aide d'un rectangle
comportant plusieurs compartiments. Les trois compartiments de base sont :
· la désignation de la classe,
· la description des attributs,
· la description des opérations.
Deux autres compartiments peuvent être aussi
indiqués :
· la description des responsabilités de la
classe,
· la description des exceptions traitées par
la classe.
Figure 6 : le diagramme de classe
métier
II.2.4. CRITIQUE DU METIER
Points positifs
Le système actuel du ministère provincial de la
jeunesse, de l'éducation, recherche scientifique et nouvelle
citoyenneté rassure le fonctionnement de l'organisation, facilite la
participation de beaucoup d'acteurs ce qui occasion l'emploi dans ladite
organisation dans la société. Le système actuel, favorise
une coopération en présentiel bien que les demandes, les
informations se font par écrit.
Points négatifs
Le système actuel du ministère nous
démontre beaucoup des difficultés entre autres la perte de
données, car tous les documents sont sous format papier ce qui cause de
perte lorsqu'on veut un document qui date de longtemps. Le système ne
participe pas à la bonne gouvernance de la chose publique de l'Etat pour
insuffisance d'informations sur les entités universitaires par le
ministère. Le système actuel prend beaucoup de temps en raison de
ses processus alors qu'il est cessé réduire le temps de
traitement.
Approche de solution
Nous proposons un système plus performant que celui qui
existe actuellement dans l'entreprise, notre système permettra à
réduire un temps de travail, à avoir assez d'informations entre
les gouvernés et les gouvernants, il se chargera aussi de stockage des
données avec l'utilisation des bases de données qui peuvent
stocker et restitués l'information. Ce nouveau système gagnera un
temps précieux pour tout déplacement puisqu'il sera aussi capable
d'envoyer et recevoir les informations en ligne sans se déplacer et
réduira le coût des agents pour une meilleure qualité. Pour
cela, l'application doit répondre aux besoins suivants :
? la publication des oeuvres scientifiques ;
? la possibilité de notifications universitaires par le
ministère ;
? la gestion des entités d'études universitaires
par le ministère de l'ESU ;
? l'échange de données d'une université X
à une université Y en ligne.
II.2. Conclusion
En résumé, ce chapitre nous a permis de faire
une étude préliminaire, l'analyse métier ainsi que la
critique métier. Il a permis de nous fixer sur les besoins fonctionnels
et non fonctionnels de notre nouveau système.
Dans le chapitre suivant, nous allons présenter et
concevoir notre système SDGU.
CHAPITRE III : CONCEPTION DU
SYSTEME SDGU
III.1. Introduction
Dans ce chapitre, nous allons aborder d'abord la conception
générale dans laquelle nous parlerons des exigences
fonctionnelles, l'analyse de cas d'utilisation et enfin parler de la conception
détaillée qui résulte de concevoir via diagramme de classe
et des différents diagrammes, dont celui de composant, de package et de
déploiement.
SECTION 1 : EXIGENCE
FONCTIONNELE DU SYSTEME
III.1.1. DIAGRAMME DE CAS
D'UTILISATION SYSTÈME
En langage UML, les diagrammes de cas d'utilisation
modélisent le comportement d'un système et permettent de capturer
ses exigences. Ils décrivent les fonctions générales et la
portée d'un système. Ces diagrammes identifient également
les interactions entre le système et ses acteurs. Les cas d'utilisation
et les acteurs dans les diagrammes de cas d'utilisation décrivent ce que
le système fait et comment les acteurs l'utilisent, mais ne montrent pas
comment le système fonctionne en interne.
Pour ce travail, chaque service possède un diagramme de
cas d'utilisation.
v Diagramme de cas d'utilisation de la Gestion des
institutions
L'acteur principal pour la gestion des institutions est le
gestionnaire DN. Ce diagramme nous montre les différentes tâches
que peut faire le gestionnaire DN dans le système. Le gestionnaire DN
peut créer une institution, modifier une institution et fermer une
institution. Mais pour se faire, il devra être inscrit ets'authentifier
par la suite pour accéder à ces fonctionnalités.
Figure 7 : le diagramme de cas d'utilisation
Gestion institutions
v Diagramme de cas d'utilisation de la gestion notification
Les acteurs sont le gestionnaire DN, le ministre et
l'utilisateur (étudiant et enseignant). Ce diagramme nous montre les
différentes tâches que peuvent faire les acteurs dans le
système. Le gestionnaire DN se charge de rédiger la notification,
le ministre s'occupe de l'autorisation de la notification avant qu'elle soit
publiée par le gestionnaire. L'utilisateur peut consulter la
notification. Pour avoir accès à toutes ces
fonctionnalités, ils devront être inscrit et s'authentifier.
Figure 5-le diagramme de
cas d'utilisation gestion notification
v Diagramme de cas d'utilisation de la gestion oeuvre
scientifique
Les acteurs sont le gestionnaire DN, le gestionnaire DA et
l'utilisateur. Ce diagramme nous montre les différentes tâches que
peut faire les acteurs dans le système. Pour avoir accès à
toutes ces fonctionnalités, ils doivent être inscrit et
s'authentifier.
Figure 6-le diagramme de
cas d'utilisation gestion oeuvre scientifique
v Diagramme de cas d'utilisation Gestion des utilisateurs
Les principaux acteurs qui peuvent voir les statistiques sont
les administrateurs. Ce diagramme nous montre que les contrôleurs peuvent
ajouter d'autres administrateurs et faire des rapports. Pour accéder
à ces fonctionnalités ils devront se connecter d'abord.
Figure 7- le diagramme de
cas d'utilisation gestion utilisateurs
III.1.2. DESCRIPTION DES CAS
D'UTILISATION
Pour la suite de l'étude de cas, nous allons poursuivre
sur les 7 cas d'utilisation :
· Le cas d'utilisation 1 « Gérer les
institutions »
· Le cas d'utilisation 2 « Gérer les
notifications »
· Le cas d'utilisation 3 « Gérer les
oeuvres scientifiques »
· Le cas d'utilisation 4 « Demander
Renseignements »
· Le cas d'utilisation 5 « Autoriser
notifications »
· Le cas d'utilisation 6 « publier oeuvres
»
· Le cas d'utilisation 7 « Créer
Utilisateurs »
Description textuelle du cas d'utilisation
Le cas d'utilisation 1 « Gérer les
institutions »
· Nom : Gérer institutions
· Résumé : cette fonctionnalité
permet de créer, supprimer, lister et fermer une institution.
· Version : 1.0
· Responsable : PK9-SDGU
· Acteur ; Gestionnaire DN
· Précondition : le Gestionnaire DN s'est
authentifié correctement à l'application.
· Scenario nominal
1. Le Gestionnaire DN demande le formulaire de gestions
universitaires
2. Le système affiche le formulaire de gestions
universitaires
3. Le Gestionnaire DN sélectionne l'action
souhaitée (créer, supprimer, lister et fermer) et valide.
4. Le système affiche les détails de l'action
5. Le Gestionnaire DN rempli les détails et valide
6. Le système réagit en fonction de l'action
effectuée en vérifiant les données saisies s'elles sont
bien remplies.
· Scenario alternatif
u Les données mal remplies
u Le système affiche le message
« error » et le cas d'utilisation se termine en
échec.
· Post-condition : le système gère les
institutions universitaires.
Le cas d'utilisation 2 « Gérer les
notifications »
· Nom : Gérer notifications
· Résumé : cette fonctionnalité
permet de créer, supprimer, modifier et publier une notification.
· Version : 1.0
· Responsable : PK9-SDGU
· Acteur ;Le Gestionnaire DN
· Précondition :Le Gestionnaire DN s'est
authentifié correctement à l'application.
· Scenario nominal
7. Le Gestionnaire DN demande le formulaire de gestions
notificatives
8. Le système affiche le formulaire de gestions
notificatives (créer, supprimer, modifier et publier)
9. Le Gestionnaire DN sélectionne l'action
souhaitée et valide.
10. Le système affiche les détails de l'action
11. Le Gestionnaire DN rempli les détails et valide
12. Le système réagit en fonction de l'action
effectuée en vérifiant les données saisies s'elles sont
bien remplies.
· Scenario alternatif
u Les données mal remplies
u Le système affiche le message
« error » et le cas d'utilisation se termine en
échec.
· Post-condition : le système gère les
notifications.
Le cas d'utilisation 3 « Gérer les oeuvres
scientifiques »
· Nom : Gérer OEuvres scientifiques
· Résumé : cette fonctionnalité
permet de créer et supprimer une oeuvre.
· Version : 1.0
· Responsable : PK9-SDGU
· Acteur ; Utilisateur (étudiant &
enseignant)
· Précondition :L'utilisateur s'est
authentifié correctement à l'application.
· Scenario nominal
13. L'utilisateur demande le formulaire de gestions oeuvres
14. Le système affiche le formulaire de gestions
oeuvres (créer, supprimer)
15. L'utilisateur sélectionne l'action souhaitée
et valide.
16. Le système affiche les détails de l'action
17. L'utilisateur rempli les détails et valide
18. Le système réagit en fonction de l'action
effectuée en vérifiant les données saisies s'elles sont
bien remplies.
· Scenario alternatif
u Les données mal remplies
u Le système affiche le message
« error » et le cas d'utilisation se termine en
échec.
· Scenario Exception
u Il y a une exception lorsqu'il y a plusieurs essayent sans
suite, le système bloque cette fonctionnalité en affichant un
message de réfléchir de nouveau pour votre oeuvre pendant 48h.
· Post-condition : le système gère les
oeuvres scientifiques.
Le cas d'utilisation 4 « Demander Renseignements
»
· Nom : Demander Renseignements
· Résumé : cette fonctionnalité
permet de formuler une demande d'information d'une entité
d'études universitaires X vers une entité d'études
universitaires Y.
· Version : 1.0
· Responsable : PK9-SDGU
· Acteur ; Gestionnaire DA
· Précondition :Le Gestionnaire DA s'est
authentifié correctement à l'application.
· Scenario nominal
19. Le Gestionnaire DA demande le formulaire de
renseignements
20. Le système affiche le formulaire de
renseignements
21. Le Gestionnaire DA rempli les informations de sa demande
et valide.
22. Le système crée la fiche de demande de
renseignements en vérifiant les données saisies s'elles sont bien
remplies.
· Scenario alternatif
u Les données mal remplies
u Le système affiche le message
« error » et le cas d'utilisation se termine en
échec.
· Post-condition : le système crée une
demande de renseignements.
Le cas d'utilisation 5 « Autoriser notifications
»
· Nom : Autoriser notifications
· Résumé : cette fonctionnalité
permet de valider la publication d'une notification.
· Version : 1.0
· Responsable : PK9-SDGU
· Acteur ; Ministre
· Précondition :Le Ministre s'est
authentifié correctement à l'application.
· Scenario nominal
23. Le ministre demande la notification gérée
24. Le système affiche la notification
gérée
25. Le ministre rempli les informations de validation et
valide.
26. Le système crée la fiche d'autorisation en
vérifiant les données saisies s'elles sont bien remplies.
· Scenario alternatif
u Les données mal remplies
u Le système affiche le message
« error » et le cas d'utilisation se termine en
échec.
· Post-condition : le système crée une
fiche d'autorisation.
Le cas d'utilisation 6 « publier oeuvres »
· Nom : publier oeuvres
· Résumé : cette fonctionnalité
permet de publier une oeuvre scientifique.
· Version : 1.0
· Responsable : PK9-SDGU
· Acteur ; Gestionnaire DA
· Précondition :Le Gestionnaire DA s'est
authentifié correctement à l'application.
· Scenario nominal
27. Le Gestionnaire DA demande les oeuvres
gérées
28. Le système affiche les oeuvres
gérées
29. Le Gestionnaire DA rempli les informations de validation
et valide.
30. Le système crée la fiche de publication en
vérifiant les données saisies s'elles sont bien remplies.
· Scenario alternatif
u Les données mal remplies
u Le système affiche le message
« error » et le cas d'utilisation se termine en
échec.
· Post-condition : le système crée une
fiche de publication.
Le cas d'utilisation 7 « Gérer
Utilisateurs »
· Nom : Gérer Utilisateurs
· Résumé : cette fonctionnalité
permet de créer, modifier et supprimer un utilisateur.
· Version : 1.0
· Responsable : PK9-SDGU
· Acteur ; Administrateur
· Précondition :L'administrateur s'est
authentifié correctement à l'application.
· Scenario nominal
31. L'administrateur demande le formulaire de gestions
utilisateurs
32. Le système affiche le formulaire utilisateur
33. L'administrateur rempli les informations et valide.
34. Le système crée un utilisateur en
vérifiant les données saisies s'elles sont bien remplies.
· Scenario alternatif
u Les données mal remplies
u Le système affiche le message
« error » et le cas d'utilisation se termine en
échec.
· Post-condition : le système crée un
utilisateur.
III.1.3. DIAGRAMME DE SEQUENCE
SYSTEME
Au stade de la description, il est possible de donner une
première représentation des diagrammes de séquence (DSE)
en considérant les interactions entre les acteurs et le système
pris dans son ensemble.
Figure 8- le diagramme de
séquence s'authentifier
Figure 9- le diagramme de
séquence gérer institutions
Figure 10- le diagramme de
séquence gérer notifications
Figure 11- le diagramme de
séquence gérer oeuvres
Figure 12- le diagramme de
séquence demander renseignements
Figure 13- le diagramme de
séquence autoriser notification
Figure 14- le diagramme de
séquence publier oeuvre
Figure 15-le diagramme de
séquence consulter notification
III.1.4. SCHEMA DE NAVIGATION
GENERALE
Est un diagramme temporaire, non modifiable, qui affiche les
résultats d'une requête sur élément de diagramme de
contexte. Dans le cadre de l'expression des exigences fonctionnelles,
l'enchaînement des futurs écrans de l'application avec les
habilitations des différents acteurs est présenté.
Figure 16: le
schéma de navigation
SECTION 2 :
CONCEPTIONDETAILLEE ou TECHNIQUE
C'est le raffinement des éléments
précédents jusqu'à l'obtention d'une forme permettant
d'écrire immédiatement les programmes.
III.2.1. DIAGRAMME
D'INTERACTION
Figure 17- le diagramme
de séquence technique GI
Figure 18-le diagramme de
séquence technique GN
Figure 19- le diagramme
de séquence technique GO
Figure 20- le diagramme
de séquence technique DR
Figure 21- le diagramme
de séquence technique AUTN
Figure 22- le diagramme
de séquence technique PO
Figure 23- le diagramme
de séquence technique CU
III.2.2. DIAGRAMME DE CLASSE
TECHNIQUE
Les diagrammes de classes sont l'un des types de diagrammes
UML les plus utiles, car ils décrivent clairement la structure d'un
système particulier en modélisant ses classes, ses attributs, ses
opérations et les relations entre ses objets. Ainsi, les diagrammes de
classes suivants représentent respectivement notre modèle
opté pour ce projet[1].
Figure 24- le
diagramme de classe technique CU GI
Figure 25- le diagramme
de classe technique CU GN
Figure 26- le diagramme
de classe technique CU GO
Figure 27- le diagramme
de classe CU DR
Figure 28- le diagramme
de classe CU P
Figure 29- le diagramme
de classe CU AUT
Figure 30- le diagramme
de classe technique CU UTI
III.2.3. DIAGRAMME DE CLASSE
RECAPITULATIF
Ce diagramme de classe intègre l'ensemble des
diagrammes de classe techniques élaborés par cas
d'utilisation.
o Diagramme de classe récapitulatif pour « le
package gestion institutions »
Figure 31-le diagramme de
classe récapitulatif pour le package gestion institutions
v Diagramme de classe récapitulatif « Le
package de gestions notifications »
Figure 32- le
diagramme de classe récapitulatif le package gestion
notification
v Diagramme de classe récapitulatif pour « le
package gestion oeuvres scientifiques »
Figure 33-le diagramme de
classe récapitulatif gestion oeuvres sc.
III.2.4. MATRICE DE VALIDATION
La matrice de validation permet de vérifier que
l'analyse du cas est complète, c'est-à-dire que tous les cas
d'utilisation métier ont été intégrés. Elle
permet aussi d'établir une correspondance entre les cas d'utilisation
métier et les cas d'utilisation d'analyse.
|
Cas d'utilisation métier
|
Cas d'utilisation d'analyse
|
|
-GERER INSTITUTIONS
|
-créer institution
-modifier institution
-fermer institution
|
|
-GERER NOTIFICATIONS
|
- créer notification
-modifier notification
-publier notification
|
|
-GERER OEUVRES SCIENTIFIQUE
|
-créer oeuvre
-modifier oeuvre
-consulter oeuvre
|
|
-DEMANDER RENSEIGNEMENTS
|
-demander Renseignements
|
|
-AUTORISER NOTIFICATIONS
|
-autoriser notifications
|
|
-CONSULTER NOTIFICATIONS
|
-consulter notifications
|
|
-PUBLIER OEUVRE
|
-publier oeuvre
-gérer utilisateur
-créer utilisateur
-modifier utilisateur
-supprimer utilisateur
-s'authentifier
|
III.2.5. DIAGRAMME DE
PAQUETAGE
Les diagrammes de package (ou diagramme de paquetages) sont
des diagrammes structurels
utilisés pour représenter
l'organisation et la disposition de divers éléments
modélisés sous
forme de paquetages. Un paquetage est un
regroupement d'éléments UML apparentés, tels que
des
diagrammes, des documents, des classes ou même d'autres paquetages. Tous
les éléments
du diagramme sont imbriqués dans des
paquetages, qui sont eux-mêmes représentés sous
Forme de dossiers de fichiers et organisés de
manière hiérarchique. Les diagrammes de paquetages sont le plus
souvent utilisés pour donner un aperçu visuel de l'architecture
en
couches d'un classifieur UML, tel qu'un système logiciel[10].
Figure 34- Le diagramme de
package système
III.2.6. DIAGRAMME DE
COMPOSANT
Un diagramme de composants a pour objectif d'illustrer la
relation entre les différents composants d'un système. Dans le
cadre de l'UML 2.0, le terme « composant » fait
référence à un module de classes qui représentent
des systèmes ou des sous-systèmes indépendants ayant la
capacité de s'interfacer avec le reste du système. [3]
Figure 35- le diagramme de
composant
III.2.7. DIAGRAMME DE
DEPLOIEMENT
Le diagramme de déploiement UML montre l'architecture
d'exécution de systèmes qui représentent l'affectation
(déploiement) des artefacts logiciels à des cibles de
déploiement. Il est utilisé pour visualiser la topologie des
composants physiques d'un système dans lequel les composants logiciels
sont déployés. Les diagrammes de déploiement sont
très utiles pour décrire les composants matériels
où les composants logiciels sont déployés. Le diagramme de
déploiement permet également de modéliser l'aspect
physique d'un système du logiciel orienté objet.
Figure 36- Le diagramme de
déploiement SDGU
III.4. Conclusion
Dans ce chapitre, nous avons conçu notre système
SDGU en présentant les diagrammes comportementaux, structurels ainsi que
fonctionnels pour la représentation de SDGU.
CHAPITRE IV : IMPLEMENTATION
DU SYSTEME SDGU
4.1. Introduction
Dans ce chapitre, nous allons démontrer et
présenter le système SDGU avec ses différents services ou
micro services, les outils de développement ainsi que l'architecture
utilisé.
4.2. Architecture logicielle
L'architecture logicielle décrit d'une manière
symbolique et schématique les différents éléments
d'un ou de plusieurs systèmes informatiques, leurs interrelations et
leurs interactions. Pour ce projet, nous allons utiliser une architecture
micro service. Les architectures de micro services sont la « nouvelle
norme ». La création de petites applications autonomes et
prêtes à l'emploi peut apporter une grande flexibilité et
une résilience accrue à notre code. Les nombreuses
fonctionnalités spécialement conçues pour Jakarta EE
facilitent la création et l'exécution des micro services en
production à grande échelle[10].
4.3. Outils de
développement
Nous avons utilisé plusieurs outils logiciels pour une
meilleure réalisation du projet. Ces différents outils nous ont
permis de faire l'ensemble des diagrammes présentés dans ce
document et d'implémenter les différents programmes
informatiques.
Les outils utilisés sont :
JAKARTA : un Framework qui représente un ensemble
de composant (aussi appelés librairies) js autonomes qui peuvent
être utilisé dans des projets web privé ou open source. Un
puissant et robuste Framework java EE pour les applications web complexe.
Un éditeur de texte : nous avons opté pour
codeReady
Visual paradigm for UML :est un logiciel permettant aux
programmeurs de mettre en place des diagrammes UML.
Enterprise Architect : un logiciel permettant de concevoir les
diagrammes UML.
Serveur d'application wildfly : ancien Jboss application
server est un serveur d'application java EE libre.
Maven : un outil de gestion et d'automatisation de production
des projets logiciels Java en général et Java EE en particulier.
Il est utilisé pour automatiser l'intégration continue lors d'un
développement de logiciel.
4.4. Création des bases de
données des différents micro services
4.4.1. Le modèle logique de
données du micro service
Figure 37- modèle
logique de données gestions institutions
Figure 38-le modèle
logique de données gestions notifications
Figure 39-modele logique de
données gestions oeuvres
4.4.2. Création de la base
de données du micro service
Figure 40- base de
données gestions institutions
Figure 41- base de
données gestions notifications
Figure 42- base de
données gestions oeuvres
4.4.3. Requête SQL
Figure 43- code SQL
gestions institutions
Figure 44- le code SQL
Gestions notifications
Figure 45- code SQL gestions
oeuvres
4.5. Interface utilisateur
Durant cette section, nous présentons un
scénario d'utilisation de l'application par quelques interfaces. Pour
pouvoir accéder au menu principal de l'application [7].
Figure 46-Interface
utilisateur gestions universitaires
Figure 47- Interface
utilisateur gestions notifications
Figure 48- Interface
utilisateur gestions oeuvres scientifiques
Figure 49-Interface
utilisateur s'authentifier
4.6. Maquette de
déploiement
Figure 50- maquette de
déploiement
Figure 51- code d'ajout deMySQL
connector
V.CONCLUSION GENERALE
En définitive l'objectif de ce mémoire
était de concevoir une architecture micro service de publication des
oeuvres scientifiques entre le ministère de l'esu et les entités
universitaires en RDC. Pour cela, nous avons conçu un système
interactif basé sur les micro services permettant de gérer les
différents traitements du système et de satisfaire les besoins
des différents utilisateurs impliqués dans ce processus.
Nous avons commencé ce travail par la
compréhension du contexte du sujet. Ensuite, nous avons
réalisé une étude dans ce domaine, afin de pouvoir noter
les manquements et les objectifs pour avoir un système satisfaisant.
Après, nous sommes passé à l'étude conceptuelle de
l'application selon une approche orientée objet tout en se basant sur le
langage UML et le processus unifié 2TUP. Enfin, nous avons abordé
l'implémentation de l'application SDGU, que nous n'avons pas pu
concrétiser pour manque de temps suffisant par rapport à
l'envergure du travail. Espérons à la génération
future pour achever ce projet si important pour le fonctionnement de notre
ministère.
Notre solution consiste à concevoir et
développer une architecture micro services du système actuel qui
corrigera les manquements et les défaillances notées. En effet,
il consiste à la communication des oeuvres scientifiques universitaires
en RDC et permettre au ministère de pouvoir communiqué avec les
entités universitaires sans se déplacer grâce à
notre système. Chaque institution est identifiée par un code.
L'application permettra aussi aux contrôleurs d'accès d'une
institution X d'avoir un système de contrôle d'accès qui
leurs permettra d'échangé avec une institution Y.
Les objectifs majeurs de ce projet sont :
? la publication des oeuvres scientifiques ;
? la possibilité de notifications universitaires par le
ministère ;
? la gestion des entités d'études universitaires
par le ministère de l'ESU ;
? l'échange de données d'une université X
à une université Y en ligne.
Ce projet est venu innover le système entre le
ministère de l'esu et les entités universitaires car il facilite
sa gestion et favorise la transparence.
VI. BIBLIOGRAPHIE
|
[1]
|
A. anli, «methodologie de developpement des systemes
d'informations personnalisés: application à un systeme
d'information au service des usagers des transports terrestres de
personnes,» chez These, 2006, p. 4.
|
|
[2]
|
z. h. EDDY caron, «Architecture Micro services
pilotée par les données,» lyon france, 28 juin
2018.
|
|
[3]
|
M. Babacar DIAGO, automatisation du systeme de restauration de
l'université Assane seck, de la vente des tickets au controle des
accès aux restaurant, ziguinchor, 04/02/2022.
|
|
[4]
|
«micros services,» www.google.com, paris, 2020.
|
|
[5]
|
P. G. c. r. xavier Fournier-Morel, le guide de l'architecture
d'un systeme information agile,SOA MICROSERVICES,API MANAGEMENT, 5em edition,
2020.
|
|
[6]
|
developpez.com,
«https://sabricole.developpez.com/uml/tutoriel/unifiedProcess,» chez
sophnouill.developpez, paris, 19/juin 2020, consulté le 20 mai
2022, p. P3;25.
|
|
[7]
|
le president de la république, «ordonnance
n°20/017 fixant les attributions des ministères,» Kinshasa,
mars 2020.
|
|
[8]
|
f. kadiata, developpement d'une application web d'archivage et
optimisation de processus d'accès aux données, tfc, lubumbashi,
UPL: inedit, 2015.
|
|
[9]
|
« Lucidchart. https://www.lucidchart.com,,»
Consulté le 13/08/2022.
|
|
[10]
|
«Spring, https://spring.io, Consulté le
10/11/2021, Disponible sur https://spring.io/microservices».
|
|
[11]
|
d. g. joseph gabay, UML 2, analyse et conception Mise en
oeuvre guidée avec etude de cas, paris: dunod, 2008.
|
Table des matières
0. INTRODUCTION
GENERALE
1
CHAPITRE I : ETAT DE L'ART SUR LES
MICROS SERVICES ET METHODE 2TUP
4
I.1. Introduction
4
SECTION 1 : CONCEPTS CLES
4
I.1.1. Les micros services
4
SECTION 2 : CADRE
METHODOLOGIQUE
7
I.2.1. Processus unifié
7
I.2.2. Processus 2TUP
7
I.2.3. Choix de la modélisation UML
9
I.5. Conclusion
11
CHAPITRE II : ANALYSE DU SYSTEME
EXISTANT
12
II.1 Introduction
12
SECTION 1 : ETUDE
PRELIMINAIRE
12
II.1.1. Présentation générale
ministère national de l'enseignement supérieur et universitaire
en RDC [5]
12
II.1.2. Présentation du domaine
d'étude
13
II.1.3. CAHIER DES CHARGES
13
II.1.4. Recueil des besoins fonctionnels
15
II.1.5. IDENTIFICATION DES ACTEURS DU SYSTEME
16
II.1.6. DIAGRAMME DE CONTEXTE DYNAMIQUE
17
II.1.7. MODELE DE CONTEXTE STATIQUE
18
SECTION II : ANALYSE
METIER
19
II.2.1. Diagramme de cas d'utilisation
métier
19
II.2.2 DIAGRAMME D'ACTIVITE
19
II.2.3. DIAGRAMME DE CLASSE METIER
21
II.2.4. CRITIQUE DU METIER
22
II.2. Conclusion
23
CHAPITRE III : CONCEPTION DU SYSTEME
SDGU
24
III.1. Introduction
24
SECTION 1 : EXIGENCE FONCTIONNELE DU
SYSTEME
24
III.1.1. DIAGRAMME DE CAS D'UTILISATION
SYSTÈME
24
III.1.2. DESCRIPTION DES CAS D'UTILISATION
28
III.1.3. DIAGRAMME DE SEQUENCE SYSTEME
33
III.1.4. SCHEMA DE NAVIGATION GENERALE
41
SECTION 2 : CONCEPTION DETAILLEE ou
TECHNIQUE
42
III.2.1. DIAGRAMME D'INTERACTION
42
III.2.2. DIAGRAMME DE CLASSE TECHNIQUE
48
III.2.3. DIAGRAMME DE CLASSE RECAPITULATIF
55
III.2.4. MATRICE DE VALIDATION
59
III.2.5. DIAGRAMME DE PAQUETAGE
60
III.2.6. DIAGRAMME DE COMPOSANT
61
III.2.7. DIAGRAMME DE DEPLOIEMENT
62
III.4. Conclusion
62
CHAPITRE IV : IMPLEMENTATION DU
SYSTEME SDGU
63
4.1. Introduction
63
4.2. Architecture logicielle
63
4.3. Outils de développement
63
4.4. Création des bases de données
des différents micro services
64
4.4.1. Le modèle logique de données
du micro service
64
4.4.2. Création de la base de données
du micro service
65
4.4.3. Requête SQL
67
4.5. Interface utilisateur
70
4.6. Maquette de déploiement
72
V.CONCLUSION GENERALE
73
VI. BIBLIOGRAPHIE
74
| 
