1

INTRODUCTION
L'évolution des techniques informatiques depuis les vingt dernières
années a permis d'adapter les outils informatiques à l'organisation des
entreprises. Vu, le grand volume de données manipulées par ces dernières, la
puissance des micro-ordinateurs, les performances des réseaux et la baisse
considérable des coûts du matériel informatique ont permis l'apparition d'une
nouvelle approche afin de remédier aux désagréments causés par la
centralisation des données, et ce en répartissant les ressources informatiques tout
en préservant leur cohérence.
L’informatique représente la révolution la plus importante et la plus
innovante qui a marqué la vie de l'humanité ces 20 dernières années. En effet,
loin d'être un éphémère phénomène de mode, ou une tendance passagère,
l'informatique vient nous apporter de multiples conforts à notre mode de vie.
Aucun domaine n'est resté étranger à cette stratégie qui offre tant de services
aussi bien pour l’enseignement, c'est dans ce cadre d'idées que s'inscrit notre
projet de fin d’études.
Les bases de données réparties sont un moyen très efficace pour
pallier aux problèmes engendrés par l'approche centralisée, mais n'en demeure
pas moins sans failles.
L’objectif visé dans notre projet de fin d’études est la
« Modélisation et l’implémentation d’une base de données répartie pour la
gestion des activités académiques dans une université » et nous avons jeté
notre dévolu sur l’université presbytérienne Sheppard et Lapsley du Congo
UPRECO en sigle qui est notre cadre pouvant nous permettre de bien mener
nos recherches en vue de développer et présenter scientifiquement notre projet.
Le but de notre projet est de nous faire palper les réalités de toutes
les connaissances acquises durant notre formation. Nous devons avouer qu’il
nous aurait été difficile de vivre les réalités pratiques et de faire la connaissance
des innovations techniques de la science informatique, dont d’énormes sacrifices
ont été consentis pour maîtriser les principes théoriques, si cette formation
n’était pas complétée par ce Mémoire de Licence.
Un système réparti est un ensemble de processeurs autonomes,
reliés par un réseau de communication, qui coopèrent pour assurer la gestion des
informations.
Un système réparti peut sensiblement améliorer les performances des
traitements. En effet, avec une localisation des données et une répartition des
traitements bien étudiées, la déperdition induite par les communications des
données inter-sites peut être compensée par le gain (temps de réponse), issu du
parallélisme dans l'exécution des traitements.
 2

La sécurité dans un système réparti vise à garantir la confidentialité,

l'intégrité de l'information et le respect des règles d'accès aux services. Les
méthodes utilisées reposent d'une part sur un matériel ou un logiciel dédié, et
d'autre part, sur des protocoles de sécurité utilisant la cryptographie.
L’UPRECO fait partie d’une intégrante des établissements
nécessitant une aide informatique car jusqu’à ce jour, la manière de gérer
manuellement est encore dominante, les différentes erreurs liées à la gestion des
activités académiques ne cessent de se produire d’où la nécessité absolue
d’introduire une application informatique dans la gestion des activités
académiques.
La finalité de ce travail est d’automatiser des informations
recueillies, cadrant avec les services organisés à l’UPRECO. Cette application
pourra servir d’interface entre les différentes facultés qui seront des sites
autonomes.
0.1. CHOIX ET INTERET DU SUJET

Chaque sujet est un choix fait par le chercheur, c’est pourquoi nous
ne pouvons pas développer cette thématique sans pour autant démontrer notre
choix et notre intérêt sur ce sujet.
Le choix porté sur ce sujet « Modélisation et implémentation d’une
base de données répartie pour la gestion des activités académiques à
l’UPRECO » revêt deux raisons.
 La première raison était de doter de l’UPRECO d’une base de données
répartie capable de remédier aux difficultés énormes qu’éprouve cette
institution dans la gestion des activités académiques
 La seconde était d’allier la théorie apprise à la pratique en vue de
sanctionner notre dernier cycle par un travail capable de refléter notre
image dans tout notre parcours
Ce projet de fin d’étude présente un triple intérêt :
 Sur le plan social : il permet aux responsables d’économiser le temps à
prendre dans la gestion et le suivi des enseignements, en économisant les
frais dans l’achat de différents outils entre autre, papiers, stylos etc.
 Sur le plan scientifique : ce travail permet au chercheur qui veut aborder
dans le domaine similaire de fouiller et en magasiner certaines
informations. Il constitue une référence pour toute recherche.
 Sur le plan individuel : Il sanctionne notre parcourt à l’UPRECO dans le
domaine scientifique et nous prépare à des grandes rédactions présentes et
futures.
 3

0.2. PROBLEMATIQUE
Nous ne pouvons pas aborder cette thématique sans pour autant
poser notre problématique qui pourra nous aider à bien mener notre étude.
La problématique constitue un facteur essentiel qui permet de faire
démarrer toute recherche scientifique en ce qu’elle pose les jalons
indispensables qui soutiendront l’entreprise scientifique du chercheur.
C’est un ensemble des questions qui constituent l’avis d’un
scientifique ou d’un chercheur selon son point de vue. C’est aussi une
expression des préoccupations majeures qui circonscrit de la façon précise et
déterminée les dimensions essentielles de l’étude que le chercheur se propose de
mener
L’UPRECO connait actuellement une faiblesse organisationnelle
énorme dans la gestion des activités académiques qui ne permet pas à cette
entreprise éducationnelle à être efficace, pour la simple raison que sa gestion est
purement manuelle, trop lente et avec beaucoup d’erreur. Vu qu’il est difficile
de conserver les documents académiques portant des données importantes
comme les relevés de cotes des étudiants, les points des certaines évaluation des
étudiants etc ; de rendre à un délai court les résultats des étudiants.
D’où notre problématique consiste à répondre aux interrogations
suivantes en rapport avec les difficultés qu’elle rencontre :
 Que faire pour rendre performent et efficace le système de gestion des
activités académiques de l’UPRECO?
 Comment l’UPRECO peut-elle arriver à conserver ses données et avoir la
traçabilité de données de différentes activités exercées dans cette
institution ?
 Que faut-il faire pour mettre fin à la gestion manuelle, lente et ambigüe
des activités dans le service académique de l’UPRECO ?

0.3. HYPOTHESES
Selon le professeur Bien-Aimé KABEMBA dans son cours de
méthode de recherche scientifique il définit les hypothèses comme des réponses
anticipées que le chercheur donnent aux questions qui forment sa problématique,
L’hypothèse de recherche est une proposition des réponses aux questions que
l’on s’est posé à propos de l’objet de la recherche, formulée dans les termes tels
 4

que l’observation et l’analyse puissent fournir une réponse. De ce fait,

l’hypothèse joue le rôle de balise pour éclairer la voie que le chercheur doit
emprunter dans son travail.

La gestion des activités académiques étant manuelle, trop lente et

avec beaucoup d’erreur, il serait mieux de mettre en place une base de données
répartie qui est un outil nécessaire capable de gérer ; conserver, minimiser le
temps et donner la traçabilité de différentes activités réalisées dans le service
académique.
0.4. METHODES ET TECHNIQUES
0.4.1. Méthodes
La méthode est définit comme un ensemble d’opérations intellectuelles
par lesquelles une discipline cherche à atteindre les vérités qu’elle poursuit les
démontrée, les vérifiée. Ainsi pour arriver à l’élaboration effective de ce travail, nous
avons usé des méthodes ci-après :

 La méthode de structure fonctionnelle : elle nous a permis d’étudier le

fonctionnement de la structure générale qui est notre champ d’étude
 La méthode analytique : basée sur l’analyse de données celle-ci nous a
permis d’analyser le système existant en vue de déceler les points forts et
les points faibles de ce dernier

0.4.2. Techniques
Les techniques sont des simples procédés de mesure ou de réparation, et
elles peuvent-être donc considéré comme des instruments de récoltes des données.
Elles sont les outils utiles et adaptés à une méthode pour atteindre le but que le
chercheur est en train de poursuivre. Elles sont utilisables qu’au niveau pratique c’est-
à-dire au niveau de la récolté de données. Les techniques ci-après y ont été jointes :

 La technique d’interview : qui nous a permis d’entrer en interaction avec

les dirigeants de notre milieu d’étude en vue d’avoir des informations
sûres et claires sur notre thématique
 La technique documentaire : celle-ci nous a permis de consulter certains
documents pour rendre effective la réalisation de ce travail
 La technique d’observation : ici les yeux en ont été un instrument
nécessaire pour palper du doigt la manière dont certaines tâches ont été
exercées sans poser des questions
0.5. DELIMITATION DU SUJET
 5

Le chercheur ne peut pas aborder toutes les dimensions mais il

établit un champ de batail précis et une durée précise en vue que la recherche
soit limitée. Ce sujet est délimité dans le temps et dans l’espace.
 Dans le temps : il couvre la période allant du 28 Novembre 2022 au 19
septembre 2023
 Dans l’espace : L’université presbytérienne Sheppard et Lapsley du
Congo reste notre espace d’investigation

0.6. SUBDIVISION DU TRAVAIL

Chaque travail scientifique doit être subdivisé pour bien évoluer
dans le souci d’aborder souvent les parties les plus faciles.
Sur ce, notre travail se subdivise en quatre chapitre outre
l’introduction générale et la conclusion générale.
 Le chapitre premier passe en revue de toutes les généralités apprises sur
les bases de données réparties
 Le second chapitre fait l’étude préalable et planifie le projet en vue de
déterminer le calendrier de l’élaboration du projet
 Le troisième chapitre nous permettra de modéliser en utilisant le langage
de modélisation unifiée
 Le quatrième chapitre nous permettra d’achever notre travail en
implémentant notre base de données répartie.
 6

CHAPITRE I : GENERALITES SUR LES BASES DES DONNEES

REPARTIES
I.1. Introduction
L’évolution des techniques informatique depuis les vingt dernières
années a permis d’adapter les outils informatiques à l’organisation des
entreprises. Vu le grand volume de données manipulées par ces dernières. Les
matériels informatiques on permit l’application d’une nouvelle approche afin de
remédier aux désagréments causés par la centralisation de données et ce, en
répartissant la ressource informatique tout en préservant la cohérence.
Les bases de données repartie sont un moyen très efficace pour
pallier aux problèmes engendrés par l’approche centralisée, mais n’en demeure
pas moins sans failles.1
I.2. Evolution des bases de données reparties
Les entreprises modernes, de nos jours se démarquent des autres
grâce à leur capacité à traiter les informations avec fiabilité et rapidité. Ainsi, la
gestion des informations prend une place prépondérante dans le développement
et l'atteinte des objectifs de l'organisation. Un système d'information renferme
l'ensemble des éléments participant à la gestion, au traitement, au transport et à
la diffusion de l'information au sein de l'organisation. Très concrètement, il peut
être très différent d'une organisation à une autre et peut recouvrir selon les cas,
tout ou une partie des éléments suivants :
1. Bases de données de l'entreprise,
2. Progiciel de gestion intégré,
3. Outils de gestion de la relation client,
4. Interface réseau,
5. Serveur de données et systèmes de stockage,
6. Serveur d'application,
7. Dispositifs de sécurité2.

1
Danièle DROMARD et Dominique SERET, Base des Données, Pearson Education, Paris, 2009, p. 24.
2
Ass Freddy ETSHIKO, cours de base de données réparties L1 informatique UPRECO 2021-2022 inédit
 7

Figure 1-1 Evolution des bases de données reparties

I.3. Système reparti3
Un système réparti est un ensemble de processeurs autonomes,
reliés par un réseau de communication, qui coopèrent pour assurer la gestion des
informations.
Le principe est simple : les données et traitements sont répartis sur
différents sites interconnectés par un réseau de communication. Ainsi, la
défaillance d'un site ne peut entraîner l'indisponibilité totale du système et sa
probabilité peut être négligée grâce à la tolérance aux fautes, assurée par la
redondance des informations et des traitements.
L'autonomie des sites est préservée par ce genre de système, en
permettant à un groupe d'utilisateurs de créer et de gérer leur propre base de
données tout en autorisant les accès aux autres utilisateurs via le réseau.
3
Ass Freddy ETSHIKO, cours de base de données réparties L1 informatique UPRECO 2021-2022 inédit
 8

Un système réparti peut sensiblement améliorer les performances

des traitements.
En effet, avec une localisation des données et une répartition des
traitements bien étudiées, la déperdition induite par les communications des
données inter-sites peut être compensée par le gain (temps de réponse), issu du
parallélisme dans l'exécution des traitements.
La sécurité dans un système réparti vise à garantir la confidentialité,
l'intégrité de l'information et le respect des règles d'accès aux services. Les
méthodes utilisées reposent d'une part sur un matériel ou un logiciel dédié, et
d'autre part, sur des protocoles de sécurité utilisant la cryptographie.

I.3.1. Architecture des systèmes répartis

Les systèmes répartis recouvrent diverses architectures depuis les
architectures Client / Serveur jusqu'aux architectures totalement réparties.
L'architecture Client/Serveur se base sur deux types de processeurs
généralement distincts :
 Les serveurs qui offrent un service à des clients, par exemple un serveur
base de données ou un serveur imprimante;
 Les clients qui émettent des requêtes aux serveurs pour les besoins d'une
application.
Dans l'architecture Client / Serveur la plus simple, la quasi-totalité du SGBD se
trouve sur le serveur, les processeurs clients ne disposant que des mécanismes
de décodage et de transmission des requêtes vers ce serveur.
Une architecture totalement répartie est une généralisation de l'architecture
Client / Serveur : les processeurs sont autonomes dans le sens où ils peuvent
disposer d'un SGBD et assurer la pleine gestion d'une base de données locale
(BDL). En plus, s'ils ne disposent pas des ressources nécessaires à une
application qui leur est soumise, ils déterminent la localisation des données et
des traitements qui leur sont nécessaires et établissent une coopération avec les
processeurs détenteurs de ces ressources.
Cette architecture permet d'éviter la présence du goulot d'étranglement du
serveur base de données puisque les données sont réparties voir dupliquées à
travers le réseau.
1.3.2 Objectifs des systèmes répartis
Au niveau des objectifs des systèmes répartis, il existe quatre points essentiels :
1. Indépendance à la localisation.
2. Indépendance à la fragmentation.
 9

3. Indépendance aux SGBDs.

4. Autonomie des sites.
1.3.2.1 Indépendance à la localisation
Au niveau des SGBDR5, l'objectif principal est de permettre
l'écriture des programmes d'application sans que l'utilisateur se soucie de la
localisation physique des données. Dans ce but, les noms des données ne doivent
pas dépendre de leurs localisations.
Les requêtes locales sont similaires aux requêtes exprimées en SQL.
Les avantages de la transparence sont de faciliter l'écriture des requêtes pour
l'utilisateur et permettre le déplacement des données sans modifier les requêtes.

1.3.2.2 Indépendance à la fragmentation

Dans un système réparti, une relation est constituée de différents
fragments, situés sur des sites différents. La relation de base ne doit pas
dépendre de la manière dont les données ont été découpées et doit pouvoir être
modifiée sans altérer les programmes.
1.3.2.3 Indépendance aux SGBDs
Un système réparti ne doit pas être dépendant en aucun cas des
différents SGBDs, la relation globale doit être exprimée dans un langage
normalisé indépendant des constructeurs.
1.3.2.4. Autonomie des sites
Vise à garder une administration locale séparée et indépendante
pour chaque serveur participant à la base de données répartie afin d'éviter une
administration centralisée.
Toute manipulation sur un site (reprise après panne, mises à jour
des logiciels) ne doit pas altérer le fonctionnement des autres sites. Bien que
chaque base travaille avec les autres, la gestion des schémas doit donc rester
indépendante d'un site à l'autre et chaque base doit conserver son dictionnaire
local contenant les schémas locaux.
1.3.2.5. Inconvénients des systèmes répartis
Malgré tous les avantages que les systèmes répartis présentent, cela
n'exclut pas l'apparition de certains inconvénients comme la complexité des
mécanismes de décomposition de requêtes, la synchronisation des traitements et
le maintien de la cohérence due à la répartition de la base de données sur
plusieurs sites, ainsi le cout induit par les transmissions des données sur les
réseaux locaux.
 10

I.4. Principe des bases de données repartie

Ces dernières années, les techniques informatiques évoluent vers le
traitement des grandes masses d’informations de nature diverse, intégrées dans
un environnement géographiquement reparti. Ainsi, les bases de données
reparties sont des solutions importantes pour parvenir à maitriser la distribution
de données4.
Dans ce contexte, et vue la souplesse des SGBDs d'une part et les
performances des réseaux d'autre part, les bases de doonées réparties sont une
solution importante pour parvenir à maîtriser la distribution des données.

I.5. Base des données reparties

1. Définition
Selon Laurent Audibert, une base des données informatisées est un
ensemble structuré de données enregistrées sur des supports accessibles par
l'ordinateur représentant des informations du monde réel et pouvant être
interrogées et mises à jour par une communauté d'utilisateurs.
Selon Mokrane Bouzeghoub, Georges Gardarin et Patrick Valduriz,
une base des données est une organisation cohérente de données permanentes et
accessibles par des utilisateurs concurrents.
Selon professeur Mvibudulu, une base des données est définie
comme étant un ensemble des données structurées, non redondantes et
exhaustives.
Une base de données est un ensemble de données structurées, non
redondantes et exhaustives, gérées par l’ordinateur. En d’autres termes est un
ensemble structuré de données enregistrées sur des supports accessibles par
l’ordinateur représentant les informations du monde réel et pouvant être
interrogées et mise à jour par une communauté d’utilisateur.5
Pour notre part, une base de données est définie comme une entité
dans laquelle les données sont structurées et exhaustives en vue d'une éventuelle
utilisation.
Une base des données répartie BDR est une collection de bases de
données localisées sur différents sites, généralement distants, mises en relations
les unes avec les autres à travers un réseau d'ordinateurs, perçues pour
4
Laurent Audibert, Base des Données, Pearson Education, Paris, 2009, p. 24.
5
Assistant Cédrick MUAMBA, cours de SGBD Access G2 Info/UPRECO 2019-2020
 11

l'utilisateur comme une base de données unique. Elle permet de rassembler des
données plus ou moins hétérogènes, disséminées dans un réseau sous forme
d'une base de données globale, homogène et intégrée.6
Une base des données répartie (distribuée) est une collection de
base des données logiquement reliées, distribuées sur un réseau. Une base des
données réparties(en anglais Distributed Data Base ou DDB) permet de
rassembler des ensembles de données plus ou moins hétérogènes, disséminées
dans un réseau d'ordinateurs, sous forme d'une base de données globale,
homogène et intégrée.
Une base des données réparties est un ensemble structuré et
cohérent de données, stocké sur des processeurs distinctes et géré par un SGBD
répartie.
Une base de données distribuée est une base de données gérée par
plusieurs processeurs, sites ou SGBD, tout en cachant la complexité des
opérations aux utilisateurs qui à leur tour pensent qu'ils accèdent à une base de
données centralisée. Une base des données répartie est un ensemble
d'ordinateurs indépendants qui apparait à un utilisateur comme un système
unique et cohérent.
Pour nous, Une base des données reparties (BDR) est un ensemble
structuré, non redondant, exhaustif et cohérent de données, qui se trouvent sur
les processeurs distincts, et géré par un système de gestion de base de données
réparties.
2. Utilité d'une base des données reparties
Une base des données réparties permet de mettre des données à la
disposition des utilisateurs pour une consultation, une saisie ou bien une mise à
jour, tout en s'assurant des droits accordés à ces derniers. Cela est d'autant plus
utile que les données informatiques sont de plus en plus nombreuses. Une base
des données peut être locale, c'est-à-dire utilisable sur une machine par un
utilisateur, ou bien répartie c'est-à-dire que les informations sont stockées sur
des machines distantes et accessibles par réseau. L'avantage majeur de
l'utilisation de base des données réparties est la possibilité de pouvoir être
accédées par plusieurs utilisateurs simultanément. Toutefois, la mise en place
d'une base des données réparties permet à l'entreprise de devenir plus
entreprenante et d'avoir une meilleure connaissance sur ses activités de loin ou
de près. Ainsi, ces données doivent être homogènes afin de permettre l'analyse
des indicateurs pertinents pour faciliter la prise de décision par les décideurs de
l'entreprise.
6
Assistant Freddy ETSHIKO, cours de base de données réparties L1 informatique UPRECO 2021-2022 inédit
 12

3. Différents types des bases des données7

Les différents types de base des données sont :

- Les bases des données hiérarchiques ;

- Les bases des données réseaux ;
- Les bases des données relationnelles qui sont les plus utilisées. Elles se
présentent sous forme d'un tableau constitué des lignes et des colonnes.
Les colonnes sont les champs de la table tandis que les lignes en sont
les enregistrements.
- Les bases de données non relationnelles ou NoSQL

4. Objectifs d'une base des données repartie8

Les objectifs d'une base des données répartie sont les suivants :
 Autonomie locale : qui implique que chaque site doit fonctionner
indépendamment des autres, même si ces derniers venaient d'avoir des
pannes;
 Ne pas se reposer sur un site unique : cet objectif vise à éviter des arrêts
de production lorsqu'un site tombe en panne ;
 Opération en continu : ici, il est question d'assurer le fonctionnement
continu du système réparti par des mises à jour et maintenance
effectuées ;
 Transparence à la localisation des données : ici, l'objectif est de
permettre d'écrire des programmes d'applications sans connaitre la
localisation physiques des données ;
 Transparence de la localisation : a pour but de rendre l'accès aux
données transparentes sur tout le réseau. En effet, ni les applications, ni
les utilisateurs ne doivent savoir la localisation des informations qu'ils
utilisent ;
 Meilleure disponibilité : une des justifications essentielles d'un SGBDR
est sans doute l'apport en matière de disponibilité des données. Tout
d'abord la répartition permet de ne plus dépendre d'un site central unique.
Surtout, elle permet de gérer des copies, de se replier sur une copie
lorsqu'une autre est indisponible (site en panne), et même de mettre à jour
de manière indépendante des copies. Les copies deviennent alors des
7
Guy PUJOLLE, Base des Données Edition 2008, Paris, Eyrolles, 6ème Ed, 2008, p. 42.
8
David TILLOY, Introduction à la conception, Paris, Ed. Amiens, 1999, p. 22.
 13

réplicas qui peuvent évoluer indépendamment pour converger

ultérieurement. Assurer une meilleure disponibilité des données c'est aussi
garantir l'atomicité des transactions ;
 Indépendance vis-à-vis de la fragmentation : la fragmentation doit être
réelle et respectée sur chaque site indépendamment.

5. caractéristiques de base des données distribuée9

Les caractéristiques de base des données distribuée (répartie) sont les suivantes :
 Centraliser l'information pour éviter les redondances, garantir l'unicité des
saisies et la centralisation des contrôles ;
 Partage de l'information entre différents utilisateurs ;
 Préservation de la cohérence des données dans le temps. La fonction de
cohérence inclut aussi tous les aspects relatifs à la sécurité en cas de
panne matérielle ou logicielle. Enfin, l'archivage est assuré par le SGBD
(Back up) de même que la technique de restauration (recovery).

6. Avantages de BDR
Les principaux avantages d'une BDR sont :
 Le gain en performance : les traitements se font en parallèles ;
 La fiabilité : si un site a une panne, un autre peut le remplacer
valablement
 La transparence des données : les développeurs et les utilisateurs n'ont pas
à se préoccuper de la localisation des données qu'ils utilisent ;
 Disponibilité des données à chaque instant et à tout lieu.

Figure 1-2 Avantages de BDR

7. Inconvénients de BDDR
Nous avons :

9
Idem
 14

o La complexité des mécanismes de décomposition de requêtes ;

o La synchronisation des traitements et le maintien de la cohérence due à la
répartition de la base de données sur plusieurs sites ;
o Le coût induit par les transmissions des données sur les réseaux locaux ;
o Les données de chaque serveur sont visibles dans d'autres serveurs, donc
pas de secret.

8. Répartition des données

La localisation d'une donnée peut prendre diverses formes dans le
cadre des systèmes répartis. Une donnée X peut être centralisée c'est-à-dire
localisée sur un seul site. Si ceci facilite le maintien de sa cohérence, il n'en va
pas de même pour les performances et la résistance aux défaillances ; en effet,
toute lecture ou écriture doit être sous-traitée au site qui supporte la donnée et la
défaillance de ce site rend la donnée inaccessible. Une autre approche à la
distribution d'une donnée consiste à la partitionner (on parle aussi de
fragmentation). Certains sites possèdent alors une partie de X et il faut
recomposer ces parties pour connaître la valeur de X. Ainsi, pour certaines
applications le partitionnement d'un fichier permet de ne placer sur chaque site
que la partie du fichier qui le concerne et qu'il va donc lire et écrire.

Une autre approche à la distribution des données consiste à les

dupliquer. Il existe alors une copie de la donnée X par site concerné par la
duplication. Une telle solution d'une part les lectures qui sont alors toutes
locales, et d'autre part la résistance aux défaillances des sites : en effet, tant qu'il
reste un site possédant une copie de X cette donnée est accessible depuis les
autres sites. La difficulté de la duplication réside dans la mise en œuvre des
opérations de lecture et d'écriture ; les différentes copies de X ne doivent en effet
pas diverger les unes par rapport aux autres, on parle de « cohérence mutuelle »
des copies.
9. Réplication dans les BDR 10
La réplication consiste à copier les informations d'une base des
données sur une autre, c'est-à-dire la reproduction identique de données d'un site
à un autre.

10
Daniel CHARNAY, Philippe CHALEAT, Système d’Information, Paris, Eyrolles, 1998, p.1.
 15

Figure 1-3 Réplication dans les BDR

L'objectif de la réplication est de faciliter l'accès aux données en
augmentant la disponibilité et aussi d'assurer la fiabilité et diminuer les trafics
réseaux.
On doit se poser cette question : « pourquoi répliquer ? ». A cette
question, deux intérêts majeurs se dégagent : améliorer les performances et
augmenter la disponibilité des données. Grâce à la réplication, les lectures sont
exécutées sur le site disposant de la copie la plus proche du client, ce qui peut
éviter des transferts inutiles, par exemple si le client dispose d'une copie. Aussi
bien pour les lectures que pour les écritures, la réplication permet d'éviter le
goulot d'étranglement que constitue le serveur unique en partageant la charge.
Du point de vue disponibilité, lors d'une panne d'un serveur, on
peut se replier sur un autre disposant d'une copie des données. 11
Si la réplication présente de nombreux avantages, les problèmes
soulevés sont multiples. Tout d'abord, il faut assurer la convergence des copies.
Si les copies peuvent être différentes à un instant donné, elles doivent converger
vers un même état cohérent où toutes les mises à jour sont exécutées partout
dans le même ordre. La convergence peut être longue, mais elle doit survenir si
l'on arrête la production de transactions dans le système.
Ensuite, il faut offrir la transparence de gestion aux utilisateurs. Les
clients doivent croire à l'existence d'une seule copie ; en conséquence, le SGBD
doit assurer la diffusion des mises à jour aux copies et le choix de la meilleure
copie lors des accès.

11
Ibidem
 16

Il existe deux types de réplication : réplication asymétrique et

réplication symétrique. 12
Réplication asymétrique : cette réplication rompt la symétrie entre les
copies en distinguant un site chargé de centraliser les mises à jour c'est-à-
dire dans cette technique de gestion de copies basée sur un site primaire
seul autorisé à effectuer des mises à jour et chargé de diffuser les mises à
jour aux autres copies dites secondaires. Ce mode de réplication convient
bien aux applications à responsabilité centralisée. Il permet la distribution
de l'information centralisée, par exemple, la diffusion de catalogues, de
listes de prix, etc. Appliqué dans l'autre sens, à partir de copies de
fragments horizontaux d'une table, il permet la consolidation
d'informations disséminées, par exemple l'état des stocks sera transmis au
siège par copie du fragment local désigné comme copie maître. Il permet
aussi la diffusion de données vers des entrepôts pour l'aide au décisionnel
et l'historisation.
Ici, toute mise à jour est d'abord appliquée à la copie primaire, puis
diffusée en temps différé. Un problème de la gestion de copie asymétrique est
donc la panne du site primaire. Dans ce cas, il faut choisir un remplaçant si l'on
veut continuer les mises à jour. Celui-ci peut être fixé par l'administrateur ou élu
par un protocole spécifique de votre majoritaire. On aboutit alors à une
technique asymétrique mobile dans laquelle le site primaire change
dynamiquement selon des critères qui peuvent être liés à l'application. Le droit
de mise à jour se déplace de site en site, par exemple, au fur et à mesure de
l'évolution des données. Ceci va vers des applications de type flots de travaux
(work flow) : le site responsable de la mise à jour des commandes change au fur
et à mesure du traitement de la commande.
Réplication symétrique : a l'opposé de la réplication asymétrique, la
réplication symétrique ne privilégie aucune copie. Elle permet les mises à
jour simultanées de toutes les copies par des transactions différentes
c'est-à-dire c'est une technique de gestion de copies où chaque copie peut
être mise à jour à tout instant et assure la diffusion des mises à jour aux
autres copies.
Cette approche convient bien aux applications à responsabilité distribuée telles
que la saisie de commandes à de multiples sites, la gestion de clients mobiles, la
gestion de comptes par des agences multiples, la mise à jour de documents
stratégiques en groupe, etc.
N.B : Ici les mises à jour sont appliquées à partir de n'importe quelle copie du
site maitre et diffusées en temps réel.
12
Jean ENGELS, PHP7 cours et exercices, Paris, Eyrolles, 2017, p. 22.
 17

10.Sécurité des données

Elle recouvre deux aspects à savoir la protection des données et le
contrôle des autorisations.
La protection des données est assurée par des encryptions, on peut dire
aussi qu'il est du ressort du système d'exploitation ;
Le contrôle des autorisations doit outre garantir que les utilisateurs, ne
peuvent exécuter que les opérations qu'ils ont le droit d'exécuter mais
aussi doit restreindre l'accès aux données et les opérations exécutables
pour une multitude de groupes d'utilisateurs.Pour la base des données
réparties : Le contrôle des autorisations entraine des nouveaux problèmes
à savoir l'authentification d'utilisateurs distants. Pour cela deux solutions
sont possibles :
Les informations concernant l'authentification des utilisateurs sont
répliquées sur chaque site. Lors de l'accès à un programme sur un site
distant, l'utilisateur doit indiquer son nom et son mot de passe.
Les différents sites s'identifient lors de l'accès à un site distant comme le
ferait un utilisateur. Chaque site possède donc son nom d'utilisateur et
son mot de passe. Cette seconde solution a l'avantage de concentrer les
informations d'un utilisateur en un seul site. Comme un utilisateur accède
à la base des données généralement par le même site, cette solution est
adéquate.

11.Les mises à jour dans la BDR 13

Il existe deux types de mise à jour :
 Mise à jour synchrone ;
 Mise à jour asynchrone
.
a. MISE A JOUR SYNCHRONE (Synchronous update)
C'est un mode de distribution dans lequel toutes les sous opérations
locales effectuées suite à une mise à jour globale sont accomplies pour le
compte de la même transaction. Dans le contexte des copies, ce mode de
distribution est très utile lorsque les mises à jour effectuées sur un site doivent
être prises en compte immédiatement sur les autres sites. L'avantage essentiel de
la mise à jour synchrone est de garder toutes les données au dernier niveau de
mise à jour. Le système peut alors garantir la fourniture de la dernière version
des données quelques soit la copie accédée. Les inconvénients sont cependant
multiples, ce qui conduit beaucoup d'applications à éviter la gestion de copies
synchrones. Ce sont d'une part la nécessité de gérer des transactions multi sites
13
Jean ENGELS, Op.cit, p.26.
 18

coûteuses en ressources et d'autres parts la complexité des algorithmes de

gestion de concurrence et de panne d'un site. C'est pour cela que l'on préfère
souvent le mode de mise à jour asynchrone (encore appelé mise à jour différée).
b. MISE A JOUR ASYNCHRONE (Asynchronous update)
C'est un mode de distribution dans lequel certaines sous opérations
locales effectuées suite à une mise à jour globale sont accomplies dans des
transactions indépendantes, en temps différé. Le temps de mise à jour des copies
peut être plus ou moins différé : les transactions de report peuvent être lancées
dès que possible ou à des instants fixés par exemple le soir ou enfin de semaine.
Les applications qui supportent un tel mode de distribution, avec gestion de
copies mises en cohérence seulement périodiquement, on parle de « cohérence
lâche », sont nombreuses. Citons par exemple, la modification des prix de
catalogues de produits, la diffusion d'informations, etc. les avantages sont la
disponibilité de mettre à jour en temps choisi des données, tout en autorisant
l'accès aux versions anciennes avant la mise à niveau. Les inconvénients sont
bien sûr que l'accès à la dernière version n'est pas garanti, ce qui limite les
possibilités de mise à jour.
I.6. Système de gestion de base des données reparties14
Le SGBDR repose sur un système réparti qui est constitué d'un
ensemble de processeurs autonomes appelés sites (micro-ordinateurs, stations
de travail, etc.) reliés par un réseau de communication qui leur permet
d'échanger des données.
Un SGBDR suppose en plus que les données soient stockées sur
deux sites au moins. Ceux-ci, étant dotés de leur propre SGBD. Un SGBDR doit
offrir une gestion des priorités, des verrous et de la concurrence d'accès de la
même façon qu'un SGBD monolithique. Pour cela, il doit disposer de :

 Dictionnaire de données réparties,

 Traitement des requêtes réparties,
 Communication de données inter sites,
 Gestion de la cohérence et de la sécurité.
Le SGBDR assure la décomposition des requêtes distribuées en
sous requêtes locales envoyées à chaque site. La décomposition prend en compte
la localisation des données pour atteindre une base de données distante :
Example: SELECT * FROM Schema.table@Link_DB ;

14
Assistant Freddy ETSHIKO op.cit
 19

Pour les mises à jour, le SGBDR doit assurer la gestion des

transactions réparties ainsi vérifier les règles d'intégrité multi-bases. En cas des
bases de données hétérogènes, le SGBDR doit assurer la traduction des requêtes.
La figure ci-dessous, illustre l'architecture d'un SGBD réparti :

Figure 1-4 système de gestion de base des données reparties

1.7. Conception d’une base de données réparties

Comme dans tous les mécanismes, la phase de conception est la
plus importante et déterminante dans la mise en place d'une base de données
repartie. Le rôle du concepteur est de définir les différents fragments de la base
et, leurs localisations ; d'évaluer les différents coûts de stockage et de transfert,
et les priorités à respecter.
 20

L'administrateur doit donc prendre des décisions en fonction de

critères techniques et organisationnels avec pour objectif de minimiser le
nombre de transferts entre sites, les temps de transfert, le volume de données
transférées, les temps moyens de traitement des requêtes, le nombre de copies de
fragments, etc...
On distingue deux principaux types de conception : la conception
ascendante et la conception descendante.
1.7.1. Conception descendante (top down design)
On commence par définir un schéma conceptuel global de la base
de données répartie, puis on distribue sur les différents sites en des schémas
conceptuels locaux.
La répartition se fait donc en deux étapes, en première étape la
fragmentation, et en deuxième étape l’allocation de ces fragments aux sites.
L’approche top down est intéressante quand on part du néant. Si les BDs existent
déjà la méthode bottom up est utilisée.
Ici, on a au départ une seule base de données qu'il faut fragmenter
et allouer les fragments aux différents sites. On va donc d'un schéma global de
conception à des sous schémas locaux.
1.7.2. Conception ascendante (bottom up design)
L’approche se base sur le fait que la répartition est déjà faite, mais il
faut réussir à intégrer les différentes BDDs existantes en une seule BDD globale.
En d’autres termes, les schémas conceptuels locaux existent et il faut réussir à
les unifier dans un schéma conceptuel global.
Dans ce cas de figure, il existe plusieurs bases de données disjointes
qu'il faut réunir en une seule base de données reparties et cohérente avec un
schéma de conception global.
 21

Figure 1-5 Conception d’une base de données reparties

1.8. Fragmentation (décomposition)
La fragmentation désigne le découpage de la base globale en sous
bases selon les critères d'analyse. La fragmentation est donc le processus de
décomposition d'une base de données en un ensemble de sous bases de données.
Cette décomposition doit être sans perte d'information.
La fragmentation peut être coûteuse s’il existe des applications qui
possèdent des besoins opposés. Le concepteur choisi entre un découpage
horizontal, vertical ou mixte.
1.8.1. La fragmentation horizontale (répartition des occurrences)
Cette fragmentation consiste à faire une séparation selon les
enregistrements. On définit le critère de sélection suivant les valeurs d'un ou
plusieurs champs et la division est faite. Par exemple dans le cas d'une gestion
de contrats, on peut séparer les contrats signés à Kinshasa de ceux signés à
Kananga.
Les occurrences (enregistrements) d'une même classe (table)
peuvent être réparties dans des fragments différents.
 L'opérateur de partitionnement est la sélection (σ)
 L'opérateur de recomposition est l'union (∪)
Exemple :
Soit une base représentée de la manière ci-après :
Compte(NumCompte, TypeCompte, Montant)
La relation Compte peut être fractionnée en Compte1 et Compte2 avec la
fragmentation suivante :
Compte1 = σ [TypeCompte = 'courant'] Compte
et Compte2 = σ [TypeCompte = 'dépôt'] Compte
La recomposition de Compte est Compte1∪ Compte2
REQUETES DE LA FRAGMENTATION
Compte1
SELECT *
FROM Compte
 22

WHERE TypeCompte = 'courant' ;

Compte2
SELECT *
FROM Compte
WHERE TypeCompte = 'dépôt' ;
REQUETES DE L’UNION
Compte
SELECT *
FROM Compte
WHERE TypeCompte = 'courant' ;
UNION
SELECT *
FROM Compte
WHERE TypeCompte = 'dépôt' ;
La meilleure façon de représenter serait :
SELECT *
FROM Compte1 ;
UNION
SELECT *
FROM Compte2 ;
1.8.2. La fragmentation verticale (Répartition des attributs)
Ici, la division est faite non au niveau des données, mais de la
structure même de la base. Certains champs sont envoyés dans un fragment et
d'autres ailleurs. En continuant avec l'exemple des contrats, on peut avoir d'une
part le numéro du client, son nom et prénom, et d'autre part le numéro du client,
le lieu d'habitation, et lieu du contrat.
Toutes les valeurs des occurrences pour un même attribut se
trouvent dans le même fragment. Une fragmentation verticale est utile pour
distribuer les parties des données sur le site où chacune de ces parties est
utilisée.
 L'opérateur de partitionnement est la projection (π)
 L'opérateur de recomposition est la jointure (*)
Soit la table client(NoClient, NomClient, Prenom, Age)
 23

Le partitionnement de la table Client en deux tables :

Cli1 = π[NoClient, NomClient] Client
et Cli2 = π [Noclient, Prénom, Age] Client

La table d'origine est obtenue avec la recomposition suivante : Client = Cli1 *

Cli2
REQUETES DE LA FRAGMENTATION
Cli1
SELECT NoClient, NomClient
FROM Client ;
Client2
SELECT NoClient, Prenom, Age
FROM Client ;
REQUETES DE LA RECOMPOSITION
Client
SELECT NoClient, NomClient, Prenom, Age
FROM Cli1, Cli2
WHERE Cli1.NoClient = Cli2.NoClient ;
1.8.3. La fragmentation hybride ou mixte (Répartition de valeurs)
C'est la combinaison des deux fragmentations précédentes,
horizontale et verticale.
Les occurrences et les attributs peuvent donc être répartis dans des
partitions différentes.
 L'opération de partitionnement est une combinaison de projections et de
sélections.
 24

 L'opération de recomposition est une combinaison de jointures et

d'unions.
La relation Client est obtenue avec : (Cli3 ∪Cli5) * Cli4 * Cli6
Relation Cli3 π[NoClient, NomClient] (σ [Age <18]Client)
Relation Cli5 π [NoClient, NomClient] (σ [Age ≥18]Client)
Relation Cli4 π [NoClient, Prénom]Client
Relation Cli6 π [NoClient, Age]Client
La fragmentation mixte consiste à utiliser conjointement les deux
méthodes citées ci-dessus.
 Les trois règles de la fragmentation
La fragmentation doit respecter trois principales règles.
 Pour toute donnée de la relation originale R il doit avoir une sous relation
Ri la contenant.
 Pour toute fragmentation de la relation R en plusieurs sous relations Ri il
doit avoir un procédé inverse de reconstitution de la relation principale R.
 Aucune donnée ne doit se trouver dans plus d'un fragment sauf dans le cas
d'une fragmentation verticale où la clé primaire doit être présente partout.
1.9. L’Allocation
Lorsque le concepteur a fini de fragmenter sa base, il lui faut
ensuite allouer chaque fragment sur son site correspondant. Cette phase est
appelée Allocation. L'allocation peut être faite de plusieurs façons :
A. La réplication totale des données
Comme nous l’avons mentionné ci-haut, La réplication désigne la
reproduction identique de données d'un site à un autre. Pour des raisons de
fiabilité on peut décider de répliquer toutes les données sur tous les sites. Ainsi,
si un site est temporairement ou définitivement défaillant, on utilise simplement
un autre. Mais cette méthode n'est pas très efficace lorsque les données sont
régulièrement mises à jour car il se pose le problème de cohérence de données
B. L'absence de réplication
On peut aussi choisir de ne rien répliquer afin d'assurer une
meilleure cohérence de données. Ici, chaque donnée est mise à jour sur un seul
site. Cette méthode est plus efficace quand les données sont beaucoup plus
modifiées que lues.
C. La méthode hybride
 25

Afin de bénéficier des deux méthodes citées à la fois, celle hybride

peut être utilisé. Ainsi les données en Read Only peuvent être répliquées et les
données en Read Write pas du tout.
1.10. Les transaction
Une transaction désigne un ensemble d'opérations effectuées de
manière indivisible sur une base de données. Elle est soit validée par un Commit,
soit annulé par un rollback soit interrompue par un abort. Afin de garantir la
stabilité du système, une transaction doit validée quatre propriétés
indispensables :
1. L'Atomicité
Cette propriété signifie que toutes les opérations d'une transaction
sont menées de façon indivisible ; toutes les opérations doivent être validées, si
non tout est annulé.
2. La cohérence
La transaction doit amener le système d'un état cohérent vers un état
cohérent, telles que toutes les contraintes d'intégrités soient respectées.
3. L'isolation
Une transaction en cours ne peut révéler ses résultats à d'autres
transactions si toutes ces opérations n'ont pas été validées.
4. La durabilité
Tout résultat produit par une transaction doit être permanent et ne
doit souffrir d'aucune altération, quelques soient les pannes du système.
 Contrôle de concurrence
Afin d'améliorer les performances dans les traitements de bases de
données, il est utile de mener en parallèles plusieurs transactions. Dans ce cas,
des mécanismes sont mis en place pour gérer leurs accès concurrents aux
données.
I.11. Conclusion Partielle
Au regard de toutes les théories coulées ci-haut, il sied de noter que
ce chapitre a donné de manière précise, les notions nécessaires cadrant avec les
bases des données reparties que nous allons développer pour en faciliter la
compréhension.
Il s’agit entre autres de la définition des certains concepts
considérés comme indispensables, architecture du système, objectifs, modèles
de conception, des fonctionnalités, son enjeux, Sa conception, et tant d’autres.
 26

De façon brève, il est un fondement pour devoir réaliser la solution faisant objet
de nos recherches.

CHAPITRE II. CADRE DU PROJET ET ETUDE PREALABLE

1. CADRE DU PROJET
A. Description du projet
Dans ce point nous allons décrire le projet que nous allons mettre en
place, avant de le décrire nous allons essayer de définir dans quelques lignes ce
que c’est un projet.
1. Définition
Le mot projet est défini de plusieurs manières par les différents
auteurs et selon les différentes organisations.
Selon l’organisation mondiale de normalisation, un projet est un
processus unique qui consiste en un ensemble d’activités coordonnées et
maîtrisées, comportant des dates de début et de fin, entrepris dans le but
d’atteindre un objectif conforme à des exigences spécifiques, incluant des
contraintes de délais, de coûts et de ressources.
Les autres le définissent d’une manière étymologique « le projet
vient du latin “projectum de projicere” qui veut dire tout simplement “Quelque
chose qui vient avant que le reste ne soit fait”. Un projet est un ensemble
d’activités qui peuvent être planifié, financé et exécuté comme une unité
isolée15.

15
Doctorant Bruno K., cours de gestion de projet, L2 Info/UPRECO, 2022-2023, inédit
 27

Pour nous un projet est une idée ou une représentation abstraite

d’une chose concrète comportant un temps spécifique et des activités bien
planifier et exécuter en vue d’atteindre un objectif bien défini.
Le projet que nous allons mettre en place est intitulé «Modélisation
et implémentation d’une base de données répartie pour la gestion des activités
académiques à l’UPRECO »
Le but de ce projet est de doter de l’UPRECO d’une base de
données répartie pouvant l’aider à stocker, gérer et garder ses informations aussi
longtemps possible, ce projet le permettra aussi d’avoir la facilité de suivre à la
loupe le déroulement de certaines activités académiques dans les différentes
facultés.
B. Analyse et compréhension de besoins
Après avoir décrit notre projet dans les lignes précédente il est
impérieux de passer à l’analyse et la compréhension de besoins afin de pouvoir
déceler les différents points fort et faibles du système étudié.
La phase d’analyse a pour objectif de décrire de manière précise,
concise, correcte et compréhensible les besoins et les exigences du client. Elle
permet de s’accorder sur ce que doit faire le système ?
Sur ce, ce point nous a permis d’entrer en contact directe avec les
dirigeants de la structure concernée afin d’avoir les différentes données pouvant
faciliter notre compréhension du plus grand problème du système étudié, c’est à
partir de ces différents problèmes que nous aurions à proposer les différentes
solutions.
C. Cahier de charge
Après avoir analysé et compris les besoins, nous allons passer à
l’élaboration de notre cahier de charge.
Etape : Cahier de charge Projet : Modélisation et
Phase : Mise en place d’une implémentation d’une base de données
architecture d’une base de données répartie pour la gestion des activités
répartie académiques

Objectif : Faire la présentation de notre base de données aux gestionnaires enfin

qu’ils prennent connaissance de la manière que cette dernière sera mise en place et
comment elle va fonctionner.

Point de départ : Compréhension des besoins et analyse préalable

 28

Point d’arriver : Mettre à la disposition des gestionnaires une base de données

répartie capable de résoudre et gérer les différents problèmes liés à la gestion de
certaines activités académiques au sein de l’UPRECO.

Délai de livraison : septembre 2023

Prérequis : Disposez d’une certaine maîtrise sur la programmation et la conception

Contenu : La mise en place d’une base de données répartie, la mise à jour et la

maintenance

Observation : Le coût total du projet est estimé à 2500$. Ce projet constitue en

général un chemin critique dans sa réalisation car les tâches sont critiques donc les
dates au plus tôt sont égales aux dates au plus tard.
D. Planification du projet
Dans ce point nous allons planifier notre projet en faisant le
calendrier au plus tôt, en montrant le chemin critique et en faisant le graphe via
l’une de méthodes étudiées.

 ORDONNANCEMENT
Les problèmes de l’ordonnancement sont apparus au départ dans la
planification de projets. Le but était de gagner du temps dans la réalisation de
ces derniers. Les projets sont constitués des nombreuses étapes également
appelées tâches, des relations temporelles existent entre ces tâches c’est-à-dire
une tâche (étape) doit commencer à une date précise. Un certain nombre de
tâches doit être terminé pour pouvoir commencer une autre, deux tâches ne
peuvent pas être réalisé en même temps, chaque tâche nécessite une certaine
quantité de main d’œuvre il faut donc éviter à chaque instant la capacité totale
de la main d’œuvre. Tous ces problèmes d’ordonnancement ont été
empiriquement résolu de 1918 à 1957 avec le diagramme de Gant, c’est ainsi
que les chercheurs ont eu à mettre en place deux méthodes scientifiques basées
sur la théorie de graphe enfin de résoudre ces problèmes d’ordonnancement :
 La Méthode MPM (Méthode de Potentiel Métra) qui est la
méthode française
 La Méthode PERT (Programm Evaluation and Research Task) qui
est la méthode anglaise
Dans ce projet, nous allons utiliser la méthode française qui parait
facile dans notre compréhension, cette méthode nous a permis à planifier
 29

l’ordonnancement et organiser un planning optimal des tâches sans

compromettre la durée totale d’exécution du projet.
 METHODE DE POTENNTIEL METRA (MPM)
1. Historique
Les méthodes d’ordonnancement one été utilisées dans le domaine
militaire, de nos jours, ces méthodes sont appliquées dans tous les domaines.
Lorsqu’on souhaite atteindre un objectif dont la réalisation comporte un grand
nombre de tâches successive, l’utilité de la programmation devient très vite et
évidente.
Dans ce cas, on doit chercher à réaliser l’ensemble de tâches dans
un ordre et avec de délai, tel que l’objectif soit atteint dans un temps minimal,
ceci grâce au modèle d’ordonnancement. C’est aux années 1958 que les français
ont eu à mettre en place une méthode d’ordonnancement appelée (Méthode des
Potentiels Métra abrégée par MPM).
La solution au PCO (Problème Central d’Ordonnancement) est
donnée par le graphe potentiel MPM pondéré et aussi un réseau de transport
quasi fortement connexe, un cas particulier du réseau de transport.
2. Elément du graphe MPM
Le graphe MPM est constitué des éléments suivants :
- Chaque tâche présente un sommet (nœud)
- Chaque Arc représente une contrainte de succession
- La pondération d’un Arc donne le temps qui doit se couler au minimum
entre le début de la tâche d’origine de l’Arc et le début de la tâche
d’extrémité de l’Arc
Ci-dessous se présente notre tableau de précédent qui reprend les
tâches du projet, la durée, les tâches antérieures et nous allons aussi calculer les
dates au plus tôt et au plus tard de notre projet.
Tâches Symbole Tâche Durée en
antérieure jour
Analyse et compréhension des besoins ACB - 20
Etude de faisabilité EF ACB 11
Conception de l’architecture CA EF 14
Elaboration de cahier de charge EC CA 7
 30

Implémentation et test unitaire I EC 92

Installation et test d’intégration IT I 7
Présentation du logiciel et formation PF IT 31
Nous devons rechercher le niveau de tâches afin de déterminer le calendrier au
plus tôt pour commencer le projet.
- Niveau 0 : les tâches de niveau 0 sont celles n’ayant pas de prédécesseurs
donc les tâches qui peuvent commencer directement sans aucune entrave.
Se référant au tableau pour le niveau 0 nous avons uniquement la tâche
ACB
- Niveau 1 : Ces sont les tâches dont les tâches antérieure sont au
maximum de niveau n-1 (EF)
- Niveau 2 : (CA)
- Niveau 3 : (EC)
- Niveau 4: (I)
- Niveau 5 : (IT)
- Niveau 6 : (PF)
Après avoir recherché les niveaux, nous allons maintenant passer à
la détermination du calendrier au plus tôt pour débuter le projet.
 Niveau 0 : ACB=0
 Niveau 1 : ici on additionne la date au plus tôt de la tâche du niveau 0 et
la durée de la réalisation de la tâche.
EF=ACB+20
EF=0+20
EF=20
 Niveau 2 : la logique reste la même, on fait la sommation de la date au
plus tôt de la tâche du niveau 0 et la durée de la réalisation de la tâche
CA=EF+11
CA=20+11
CA=31
 Niveau 3 : toujours la même logique on addition la date au plus tôt de la
tâche antérieure par la durée de réalisation
EC=CA+14
EC=31+14
EC=45
 Niveau 4 : toujours la même logique on addition la date au plus tôt de la
tâche du niveau 3 par la durée de réalisation
I=EC+7
I=45+7
I=52
 31

 Niveau 5 : toujours la même logique on addition la date au plus tôt de la

tâche du niveau 4 par la durée de réalisation
IT=I+92
IT=52+92
IT=144
 Niveau 6 : toujours la même logique on addition la date au plus tôt de la
tâche du niveau 5 par la durée de réalisation
PF=IT+7
PF=144+7
PF=151
 Niveau Final : toujours la même logique on addition la date au plus tôt de
la tâche du niveau 6 par la durée de réalisation
Z=PF+31
Z=151+31
Z=182
Après avoir déterminé le calendrier au plus tôt nous devons aussi
déterminer le calendrier au plus tard pour ressortir le chemin critique.
Pour déterminer le calendrier au plus tard, on soustrait la date au
plus tard du niveau final par la durée de réalisation de tâches, ci-dessous se
présente le calendrier au plus tard dans notre graphe.
0 0 20 20 20 11 31 31 14 45 45 7 52 52 92 144 144
ACB EF CA EC I IT
7

151 151
PF
31

182 182
Z

Après avoir déterminé le calendrier au plus tôt et au plus tard nous avons trouvé
que les tâches : ACB, EF, CA, EC, I, IT, PF constituent notre chemin critique.
2. ETUDE PREALABLE
A. Présentation du milieu d’étude
Dans ce présent chapitre, nous allons connaitre le système
d’information et représenter celui-ci afin de pouvoir prélever les points forts et
faibles.
L’Université Presbytérienne Sheppard et Lapsley du Congo
U.PRE.CO en sigle est une institution privées d’enseignement supérieur et
universitaire créée à l’initiative des communautés presbytériennes au Congo
 32

(31ème CPC par ordonnance présidentielle du premier décembre 1960 publiées

au moniteur congolais du premier janvier 1961 renouvelées par ordonnance loi
du 14 février 1973) et 32ème CPK reconnue par l’arrêté royal du 27 mai 1960,
comme association sans but lucratif (ASBL) .le conseil d’administration l’avait
dénommée Université presbytérienne Sheppard et Lapsley du Congo, en sigle
«U.PRE.CO » en date du 28 septembre 1998 à Kananga, celle-ci fut précédé
respectivement par l’école unie de théologie en 1962, l’institut supérieur de
théologie en 1976 et la faculté de théologie reformée au Kasaï en 1987.
L’U.PRE.CO est reconnue par l’état congolais sous le décret
présidentiel Nº006 /0106 du 12 juin 2006 portant agrément de quelques
établissement supérieur et universitaire.
L’Université Presbytérienne Sheppard et Lapsley du Congo a
pour objectif l’enseignement scientifique de niveau supérieur et Académique des
divers domaines en vue de la formation des cadres de conception d’une élite
Nationale pouvant répondre aux besoins de la société ainsi que de l’Eglise.
L’enseignement qui est dispensé dans les facultés approuvé par le
conseil d’administration et reconnu par le ministère de l’enseignement supérieur
et universitaire ; de la recherche scientifique au niveau de graduat, de licence,
d’étude supérieur et de doctorat conformément au programme arrêté par le
conseil d’administration.
B. Situation géographique
L’Université Presbytérienne Sheppard et Lapsley du Congo
se trouve dans la commune de NDESHA, quartier KAMUPONGO, localité
NDESHA Mission, elle est bornée:
 Au nord par le village BENA KATANGA ;
 Au sud par Institut KALENDU ou National N°1 ;
 A l’Est par la rivière NDESHA ;
 A l’Ouest par la rivière TSHIKELE.

C. Organigramme général de l’UPRECO

CONSEIL D'ADMINISTRATION
 33

D. Les processus Métiers

 34

Un processus métier c’est un ensemble d’activité permettant à une

entreprise d’atteindre ses objectifs16. Dans ce point nous allons parler du
déroulement de certaines activités académiques.
1. INSCRIPTION ET REINSCRIPTION
 Graphe de flux
Dans ce sous point qui parle des inscriptions et réinscriptions des
étudiants, nous allons voir comment les étudiants sont inscrits ou réinscrits à
l’UPRECO grâce à notre graphe de flux.

Flux 1

COMMISION D' Flux 4

Flux 2 INSCRIPTION

ETUDIANT Flux 3

APPARITEUR

Flux 5 ADMINISTRATEUR
DE BUDGET
Flux 6

LEGENDE
NOM DESCRIPTION
Flux_1 Déposer les documents d’inscription
Flux_2 Payer la fiche de scolarité
Flux_3 Etablir le formulaire d’inscription
Flux_4 Déposer le rapport d’inscription
Flux_5 Payer les frais de réinscription
Flux_6 Etablir la liste définitive des étudiants reconnus

16
www.wikipedia.org, consulter le 17/04/2023 à 8h16’
 35

 Critique du processus
Ici nous allons passer au diagnostic du système existant tout en
ressortissant les points forts et les points faibles en vue d’une proposition de
solutions adéquate.
 Points forts : Le système fonctionne bien, il y’a une cohérence de
flux d’information, les agents contrôlent bien les dossiers.
 Points faibles : Le processus se passe bien selon leur organisation,
seulement qu’il y a des disfonctionnement par rapport à
l’organisation. Les agents se trouvant dans les différents sites ne
sont plus permanant, Le paiement de frais d’une manière éparpillée
ce qui peut entrainer un déficit, La non centralisation de rapport à
temps réel, ceci donne aux gens la charge de se déplacer vers le site
central pour déposer les papiers de rapport ce qui cause aussi un
problème de transport, la lenteur par rapport à la masse à inscrire.
2. ORGANISATION DE COURS
 Graphe de flux
Le plus grand rôle du service académique c’est l’organisation des
enseignements dans chaque institution supérieure, c’est ainsi l’organisation de
cours est le point le plus important dans la gestion des enseignements.

Flux 4

ENSEIGNANT

Flux 1

FACULT E Flux 3

SECRET ARIAT
Flux 2 ACADEMIQUE
 36

LEGENDE
NOM DESCRIPTION
Flux_1 Donner la disponibilité
Flux_2 Déposer l’horaire pour l’approbation
Flux_3 Valider et remettre l’horaire
Flux_4 Remettre la charge horaire et le volume d’heure
 Critique du processus
 Points forts : le processus se passe bien, les attributions de cours se
passent très bien et les agents ont bien maitrisé leur travail.
 Points faibles : quel que soit la cohérence des informations, ce
processus présente différentes lacunes, telles que ; le processus est
manuel, le suivi de cours pose un grand souci, les disponibilités ne
sont pas respectés par manque de suivi

3. EVOLUTION DE COURS
 Graphe de flux
L’évolution de cours est la manière dont le cours se passe dans
chaque promotion entre les enseignants et les enseignés.
LEGENDE

Fl ux 1
ET UDIANT
ENSEIGNANT

Fl ux 2
Fl ux 3

APPARIT EUR Fl ux 4 FACULT E

NOM DESCRIPTION
Flux_1 Faire signer la fiche d’avancement de cours
Flux_2 Déposer la fiche d’avancement de cours et le rapport de
 37

la passation du cours
Flux_3 Déposer le rapport des enseignements
Flux_4 Prendre la fiche d’avancement et le rapport de constat

 Critique du processus
 Points forts : le processus se passe bien, il y’a une cohérence de
flux d’information.
 Points faibles : malgré les points positifs de ce processus mais il
dégage certains points négatifs dans le déroulement du travail, les
fiches d’avancement sont signés frauduleusement, les heures
prestées ne sont pas respecté, le rapport de constat n’est pas déposé
par les enseignants et pas de contrôle.

4. EVALUATION
 Graphe de flux

ET UDIANT ENSEIGNANT

Fl ux 1

Fl ux 2

ADMINIST RAT EUR

DE BUDGET FACULT E
Fl ux 3

LEGENDE
NOM DESCRIPTION
Flux_1 Payer les frais de participation
Flux_2 Remettre l’examen
Flux_3 Remettre les listes des étudiants en ordre
 38

 Critique du processus
 Points forts : le processus se passe bien, le flux d’information est
cohérent
 Points faibles : pas de rapidité, les périodes d’évaluation ne sont
pas respectées, les examens ne sont pas contrôlés avant d’être posé.

5. DELIBERATION
 Graphe de flux
Après cette étape de passation des épreuves il y’a la délibération
des étudiants
Flux 4

ENSEIGNANT

FACULT E

Flux 1

APPARITEUR

Flux 2
Flux 3

SECRETAIRE
ACADEMIQUE Flux 5

LEGENDE
NOM DESCRIPTION
Flux_1 Remettre les copies des épreuves corrigées
Flux_2 Remettre les fiches de cotation
Flux_3 Donner les fiches de cotation et les copies corrigées
pour le calcul de points
 39

Flux_4 Donner rapport après tout le travail

Flux 5 Remettre tous les rapports reçus

 Critique du processus
 Points forts : le processus se passe à la quiétude, les activités
prévues se passent bien, il y’a une atténuation de certaines mesures
 Points faibles : le processus trop lent, beaucoup d’erreur dans la
publication des résultats, les résultats ne sont pas publiés à l’heure
réelle, pas d’exactitude dans le calcul des côtes, les points des
étudiants sont calculé dans les bureautiques.

6. STAGE ACADEMIQUE
 Graphe de flux
Flux 5
ADMINIST RAT EUR DE
BUDGET
Flux 1

ET UDIANT
Flux 3

Flux4

Flux 2

FACULT E
Flux 6
INST IT UT ION
ACCUILLANT E

LEGENDE
NOM DESCRIPTION
Flux_1 Payer les frais de billet de stage
Flux_2 Se présenter pour récupérer le billet
Flux_3 Signer et Remettre le billet
 40

Flux_4 Déposer le billet pour commencer le stage

Flux_5 Déposer le rapport de stage
Flux_6 Envoyez la cotation

 Critique du processus
 Points forts : le processus se passe bien, la circulation des
informations est cohérente, le système est bien maitrisé
 Points faibles : quel que soit sa positivité, le processus présente les
différentes difficultés ; pas de suivi si les étudiants effectuent le
stage ou pas, pas d’encadreur, la mauvaise orientation du système
car le rapport est déposé au budget, les rapports ne sont pas du tout
lis et corrigés.

7. TRAVAIL DE FIN DE CYCLE ET MEMOIRE

 Graphe de flux
Flux 6
ADMINISTRATEUR
DE BUDGET

Flux 1

ETUDIANT Flux 5

Flux 7

Flux 2

Flux 4
FACULTE

COMMISSION

Flux 3

LEGENDE
 41

NOM DESCRIPTION
Flux_1 Payer les frais et retirer la fiche de proposition de sujet
Flux_2 Déposer la fiche de proposition de sujet avec trois
sujets proposés
Flux_3 Remettre les sujets pour le traitement
Flux_4 Remettre les sujets déjà traités pour le partage
Flux_5 Donner la fiche d’avancement du travail avec le sujet à
traiter, les noms du directeur et codirecteur
Flux_6 Déposer cinq exemplaires du travail après l’élaboration
Flux_7 Remettre les travaux reçus pour les donner aux lecteurs

 Critique du processus
 Points forts : le processus se passe bien, le système est cohérent
 Points faibles : le traitement de sujet pose problème, pas de
commission de traitement de sujet, les travaux sont déposés au
budget ce qui n’est pas dans les normes ce qui cause trop de
préjudices pour les remettre aux lecteurs, le temps de dépôt n’est
pas respecté

Conclusion partielle
Dans ce chapitre il était question pour nous de parler de deux points
culminants qui peuvent nous aider à bien élaborer notre travail : le planning
prévisionnel et l’analyse de l’existant. Dans le planning prévisionnel nous avons
eu à planifier notre projet en vue de déterminer les dates au plutôt et au plus
tard de notre projet pour déterminer le chemin critique enfin de s’appuyer sur les
tâches critiques pour éviter le désagrément pendant le déroulement de notre
projet. Dans le deuxième point de l’analyse de l’existant nous avons analysé en
long et en large le système existant pour ressortir ses forces et ses difficultés
pour trouver des solutions adéquates.
 42

CHAPITRE III. MODELISATION AVEC UML

III.1. INTRODUCTION

Dans ce chapitre de notre projet nous allons présenter d’une

manière abstraite le nouveau système d’information en se basant sur les
différents diagrammes du langage de modélisation que nous allons utiliser. Dans
le cadre de notre projet nous allons nous référer au langage UML qui se veut un
instrument de capitalisation des savoir-faire puisqu’il propose un langage qui
soit commun à tous les experts logiciel, va dans le sens de cet assouplissement
des contraintes méthodologiques.

III.2. DEFINITION

Le langage de modélisation unifié, de l'anglais Unified Modeling

Language (UML) est un langage de modélisation graphique à base de
pictogrammes conçu pour fournir une méthode normalisée pour visualiser la
conception d'un système. Il est couramment utilisé en développement logiciel et
en conception orientée objet.17

III.3. PRESENTATION D’UML

1. UML est une norme

Fin 1997, UML est devenu une norme OMG (Object Management
Group). L'OMG est un organisme à but non lucratif, créé en 1989 à l'initiative
de grandes sociétés (HP, Sun,Unisys, American Airlines, Philips...).
Aujourd'hui, l'OMG fédère plus de 850 acteurs du monde informatique. Son rôle
est de promouvoir des standards qui garantissent l'interopérabilité entre
applications orientées objet, développées sur des réseaux hétérogènes.
L'OMG propose notamment l'architecture CORBA (Common
Object Request Broker Architecture), un modèle standard pour la construction
d'applications à objets distribués (répartis sur un réseau). CORBA fait partie
d'une vision globale de la construction d'applications réparties, appelée OMA
(Object Management Architecture) et définie par l'OMG.
Sans rentrer dans les détails, on peut résumer cette vision par la
volonté de favoriser l'essor industriel des technologies objet, en offrant un
ensemble de solutions technologiques non propriétaires, qui suppriment les
clivages techniques.
UML a été normalisé par l'OMG et intégré à l'OMA, car il
participe à cette vision et parce qu'il répond à la "philosophie" OMG. 18
17
Laurent PIECHOCKI, UML, le langage de modélisation objet unifié, P7
18
Laurent PIECHOCKI, Op.cit. P14
 43

2. UML est un langage de modélisation objet

Pour concevoir l’objet, il faut savoir "prendre de la hauteur",

ruminer avec des concepts abstraits, indépendants des langages
d'implémentation et des contraintes purement techniques. Les langages de
programmation ne sont pas un support d'analyse adéquat pour "concevoir objet".
Ils ne permettent pas de décrire des solutions en termes de concepts abstraits et
constituent un cadre trop rigide pour mener une analyse itérative.

Pour conduire une analyse objet cohérente, il ne faut pas

directement penser en termes de pointeurs, d'attributs et de tableaux, mais en
termes d'association, de propriétés et de cardinalités... Utiliser le langage de
programmation comme support de conception ne revient bien souvent qu'à
juxtaposer de manière fonctionnelle un ensemble de mécanismes
d'implémentation, pour résoudre un problème qui nécessite en réalité une
modélisation objet.

L’approche objet nécessite une analyse réfléchie, qui passe par

différentes phases exploratoires. Bien que raisonner en termes d'objets semble
naturel, l'approche fonctionnelle reste la plus intuitive pour nos esprits
cartésiens... Voilà pourquoi il ne faut pas se contenter d'une implémentation
objet, mais se discipliner à "penser objet" au cours d'une phase d'analyse
préalable. Toutes les dérives fonctionnelles de code objet ont pour origine le
non-respect des concepts de base de l'approche objet (encapsulation...) ou une
utilisation détournée de ces concepts (héritage sans classification...).

Ces dérives ne sont pas dues à de mauvaises techniques de

programmation ; la racine du mal est bien plus profonde : programmer en C++
ou en Java n'implique pas forcément concevoir objet... Les difficultés de mise en
œuvre d'une approche "réellement objet" ont engendré bien souvent des
déceptions, ce qui a longtemps constitué un obstacle important à l'essor des
technologies objet. Beaucoup ont cédé au leurre des langages de programmation
orientés objet et oublié que le code n'est qu'un "moyen".

Le respect des concepts fondamentaux de l'approche objet prime sur

la manière dont on les implémente. Ne penser qu'à travers un langage de
programmation objet détourne de l'essentiel. Pour sortir les technologies objet de
cette impasse, l'OMG propose UML. UML comble une lacune importante des
technologies objet. Il permet d'exprimer et d'élaborer des modèles objet,
indépendamment de tout langage de programmation. Il a été pensé pour servir
de support à une analyse basée sur les concepts objet.
 44

UML est un langage formel, défini par un méta modèle. Le méta modèle
d'UML décrit de manière très précise tous les éléments de modélisation (les
concepts véhiculés et manipulés par le langage) et la sémantique de ces éléments
(leur définition et le sens de leur utilisation). En d'autres termes : UML
normalise les concepts objet.

Un méta modèle permet de limiter les ambiguïtés et encourage la

construction d'outils. Il permet aussi de classer les différents concepts du
langage (selon leur niveau d'abstraction ou leur domaine d'application) et expose
ainsi clairement sa structure. Enfin, on peut noter que le méta modèle d'UML est
lui-même décrit par un méta-méta modèle de manière standardisée, à l'aide de
MOF (Meta Object Facility : norme OMG de description des méta modèles).

Véritable clé de voûte de l'OMA, UML est donc un outil

indispensable pour tous ceux qui ont compris que programmer l’objet, c'est
d'abord concevoir l’objet. UML n'est pas à l'origine des concepts objets, mais il
en constitue une étape majeure, car il unifie les différentes approches et en
donne une définition plus formelle.

3. UML est un support de communication

UML est avant tout un support de communication performant, qui

facilite la représentation et la compréhension de solutions objet. Sa notation
graphique permet d'exprimer visuellement une solution objet, ce qui facilite la
comparaison et l'évaluation de solutions. L'aspect formel de sa notation limite
les ambiguïtés et les incompréhensions.

Son indépendance par rapport aux langages de programmation, aux

domaines d'application et aux processus, en font un langage universel. La
notation graphique d'UML n'est que le support du langage. La véritable force
d'UML, c'est qu'il repose sur un méta modèle. En d'autres termes : la puissance
et l'intérêt d'UML, c'est qu'il normalise la sémantique des concepts qu'il
véhicule. Qu'une association d'héritage entre deux classes soit représentée par
une flèche terminée par un triangle ou un cercle, n'a que peu d'importance par
rapport au sens que cela donne à votre modèle.

La notation graphique est essentiellement guidée par des

considérations esthétiques, même si elle a été pensée dans ses moindres détails.
Par contre, utiliser une relation d'héritage, reflète l'intention de donner à votre
modèle un sens particulier. Un "bon" langage de modélisation doit permettre à
n'importe qui de déchiffrer cette intention de manière non équivoque. Il est donc
 45

primordial de s'accorder sur la sémantique des éléments de modélisation, bien

avant de s'intéresser à la manière de les représenter.

Le méta modèle UML apporte une solution à ce problème

fondamental. UML est donc bien plus qu'un simple outil qui permet de
"dessiner" des représentations mentales... Il permet de parler un langage
commun, normalisé mais accessible, car visuel.

4. UML est un cadre méthodologique

Une autre caractéristique importante d'UML, est qu'il cadre

l'analyse. UML permet de représenter un système selon différentes vues
complémentaires : les diagrammes. Un diagramme UML est une représentation
graphique, qui s'intéresse à un aspect précis du modèle ; c'est une perspective du
modèle. Chaque type de diagramme UML possède une structure (les types des
éléments de modélisation qui le composent sont prédéfinis) et véhicule une
sémantique précise (il offre toujours la même vue d'un système).

Combinés, les différents types de diagrammes UML offrent une vue

complète des aspects statiques et dynamiques d'un système. Les diagrammes
permettent donc d'inspecter un modèle selon différentes perspectives et guident
l'utilisation des éléments de modélisation (les concepts objet), car ils possèdent
une structure. Une caractéristique importante des diagrammes UML, est qu'ils
supportent l'abstraction. Cela permet de mieux contrôler la complexité dans
l'expression et l'élaboration des solutions objet.

UML opte en effet pour l'élaboration des modèles, plutôt que pour
une approche qui impose une barrière stricte entre analyse et conception. Les
modèles d'analyse et de conception ne diffèrent que par leur niveau de détail, il
n'y a pas de différence dans les concepts utilisés. UML n'introduit pas d'éléments
de modélisation propres à une activité (analyse, conception...) ; le langage reste
le même à tous les niveaux d'abstraction. Cette approche simplificatrice facilite
le passage entre les niveaux d'abstraction.

L'élaboration encourage une approche non linéaire, les "retours en

arrière" entre niveaux d'abstraction différents sont facilités et la traçabilité entre
modèles de niveaux différents est assurée par l'unicité du langage. UML favorise
donc le prototypage, et c'est là une de ses forces. En effet, modéliser une
application n'est pas une activité linéaire. Il s'agit d'une tâche très complexe, qui
nécessite une approche itérative, car il est plus efficace de construire et valider
par étapes, ce qui est difficile à cerner et maîtriser.
 46

UML permet donc non seulement de représenter et de manipuler les

concepts objet, il sous-entend une démarche d'analyse qui permet de concevoir
une solution objet de manière itérative, grâce aux diagrammes, qui supportent
l'abstraction.
5. UML n'est pas une méthod
UML est un langage qui permet de représenter des modèles, mais il
ne définit pas le processus d'élaboration des modèles. Qualifier UML de
"méthode objet" n'est donc pas tout à fait approprié. Une méthode propose aussi
un processus, qui régit notamment l'enchaînement des activités de production
d'une entreprise. Or UML n'a pas été pensé pour régir les activités de
l'entreprise.
Les auteurs d'UML sont tout à fait conscients de l'importance du
processus, mais ce sujet a été intentionnellement exclu des travaux de l'OMG.
Comment prendre en compte toutes les organisations et cultures d'entreprises ?
Un processus est adapté (donc très lié) au domaine d'activité de l'entreprise ;
même s'il constitue un cadre général, il faut l'adapter au contexte de l'entreprise.

Bref, améliorer un processus est une discipline à part entière, c'est

un objectif qui dépasse très largement le cadre de l'OMA. Cependant, même si
pour l'OMG, l'acceptabilité industrielle de la modélisation objet passe d'abord
par la disponibilité d'un langage d'analyse objet performant et standard, les
auteurs d'UML préconisent d'utiliser une démarche :

 guidée par les besoins des utilisateurs du système,

 centrée sur l'architecture logicielle,
 itérative et incrémentale.

D'après les auteurs d'UML, un processus de développement qui

possède ces qualités fondamentales "devrait" favoriser la réussite d'un projet.
Une source fréquente de malentendus sur UML a pour origine la faculté d'UML
de modéliser un processus, pour le documenter et l'optimiser par exemple. En fin
de compte, qu'est-ce qu'un processus ? Un ensemble d'activités coordonnées et
régulées, en partie ordonnées, dont le but est de créer un produit (matériel ou
intellectuel). UML permet tout à fait de modéliser les activités (c'est-à dire la
dynamique) d'un processus, de décrire le rôle des acteurs du processus, la
structure des éléments manipulés et produits, etc...

Une extension d'UML ("UML extension for business modeling")

propose d'ailleurs un certain nombre de stéréotypes standards (extensions du
métamodèle) pour mieux décrire les processus. Le RUP ("Rational Unified
Process"), processus de développement "clé en main", proposé par Rational
 47

Software, est lui aussi modélisé (documenté) avec UML. Il offre un cadre
méthodologique générique qui repose sur UML et la suite d'outils Rational.

III.4. LE PROCESSUS UP

UML est un langage qui permet de représenter des modèles, mais il

ne définit pas le processus d’élaboration des modèles. De ce fait, il faudra
choisir un processus (démarche à suivre) pour pouvoir modéliser avec ce
langage. Plusieurs processus existent parmi eux le Processus Unifier UP.19
Complément idéal d’UML, le processus unifié (UP pour unified
process) est le processus de développement logiciel né de la fusion des travaux
d’Ivar Jacobson, Grady Booch et de James Rumbaugh, les trois concepteurs du
langage UML.
Fruit des meilleures pratiques de l’ingénierie logicielle, le processus unifié décrit
les activités qui permettent de traduire les besoins d’un utilisateur en un système
logiciel. Le processus unifié est décrit par ses auteurs comme une méthode
pilotée par les cas d’utilisation, centrée sur l’architecture, itérative et
incrémentale.

 DISCIPLINES D’UP

Les disciplines permettent de regrouper les différentes activités du

PU en six disciplines d’ingénierie (workflows du processus), directement liées
au processus de développement, et trois disciplines de support (workflow de
soutien).

Les neufs disciplines d’UP sont :

1. La modélisation du métier : Il s’agit d’identifier les acteurs, les

processus métier et la vision métier que le projet doit implémenter.
2. La gestion des exigences : Basée sur les cas d’utilisation, est une
discipline essentielle d’UP qui vise à capturer le plus fidèlement possible
les exigences des utilisateurs du projet.
3. L’analyse et la conception : Ont pour objectif de traduire les cas
d’utilisation en autant de vues de l’architecture du logiciel que nécessaire.
Cette discipline peut exploiter la palette des diagrammes UML pour la
production de ces différentes vues.
4. L’implémentation : Vise le triple objectif de raffiner le modèle de
conception, générer le code source et les tests unitaires associés, intégrer
le travail d’implémentation des différentes équipes travaillant en parallèle

19
Laurent PIECHOCKI, Op.cit. p14
 48

5. Les tests : Jouent un rôle central dans le PU. Ils sont continuellement mis
en œuvre pendant le processus de développement. Ils doivent également
comprendre des tests de non régression essentiels dans tout processus
incrémental.
6. Le déploiement : Prend en charge les activités de configuration et de
conditionnement du système à livre.
7. La gestion de la configuration et des changements : Cette discipline
utilisera avantageusement des systèmes de gestion de versions comme
CVS (Concurrent Versions system) par exemple.
8. La gestion de projet : Est une discipline critique du PU qui la
responsabilité de planifier et de piloter l’ensemble des activités du projet.
9. L’environnement : Est la discipline responsable de la logistique au sens
large du projet : normes, standards, environnement de développement,
infrastructure matérielle…

 PHASE DU PROCESSUS UNIFIE

Les itérations d’UP s’inscrivent dans quatre phases successives dont

la validation constitue des jalons importants du processus de développement :

a. Initialisation : La phase d’initialisation a pour objectif de trouver un

compromis entre les exigences et contraintes.

b. Elaboration : Cette phase devrait également conduire à une révision et

une précision du planning du projet.

c. Construction : C’est dans cette phase que la capture des exigences doit
être finalisée, mais aussi et surtout, que les différents incréments de
l’application doivent être conçus et implémentés.

d. Transition : Cette phase consiste à finaliser le produit et à effectuer la

livraison du système auprès des utilisateurs finaux.

III.5. LES DIAGRAMMES

Les diagrammes sont des éléments graphiques, ceux-ci décrivent le

contenu des vues, qui sont des notations abstraites. Les diagrammes peuvent
faire partie de plusieurs vues.
 49

 DIAGRAMME STRUCTURELLE OU STATIQUE :

a. Diagramme de classe

Un diagramme des classes décrit le type des objets du système ainsi

que les différentes formes de relation statique qui les relient entre eux. On
distingue classiquement deux types principaux de relation entre objets :
Les associations, bien connues des vieux modèles entité/association utilisés dans
la conception des bases de données depuis les années 70 ; Les sous types,
particulièrement en vogue en conception orientée objets, puisqu’ ils s’expriment
très bien à l’aide de l’héritage en programmation.

b. Diagramme d’objet

Un objet est une instance d’une classe, un diagramme d’objets est

un ensemble d’objets respectant les contraintes du diagramme de classe, respect
des cardinalités. Chaque attribut d’une classe a une valeur affectée dans chaque
instance de cette classe.

c. Diagramme de composant

Il permet de montrer les composants du système d’un point de vue

physique, tels qu’ils sont mise en œuvre.

d. Diagramme de déploiement

Il sert à représenter les éléments matériels et la manière dont les

composants du système sont répartis sur ces éléments matériels et interagissent
entre eux.

e. Diagramme de paquetages

Le diagramme de paquetage sert à représenter les dépendances

entre paquetage. C’est- à dire les dépendances entre ensembles de définition.

f. Diagramme de structure composite

Permet de décrire sous forme de boite blanche les relations entre

composants d’une classe.

 DIAGRAMME DE COMPORTEMENT
 50

a. Diagramme de cas d’utilisation

Un cas d’utilisation modélise une interaction entre le système

informatique à développer et un utilisateur ou un acteur interagissant avec le
système. Plus précisément, un cas d’utilisation décrit une séquence d’actions
réalisées par le système qui produit un résultat observable pour un acteur.

Il y a en général deux types de description des use cases :

 Une description textuelle de chaque cas ; où Le diagramme des cas

d’utilisation qui présente une synthèse de l’ensemble des cas ;
 Dépendances entre cas d’utilisation : Il est parfois intéressant d’utiliser
des liens entre cas, UML en fournit deux types :

 La relation utilise (include) : est employée quand deux cas

d’utilisation ont en commun une même fonctionnalité et que l’on
souhaite factoriser celle-ci en créant un sous cas, ou cas intermédiaire,
afin de marquer les différences d’utilisation.
 La relation étend (ex-tend) : nous dirons qu’il y a extension d’un cas
d’utilisation quand un cas est globalement similaire à un autre ou
lorsque un cas doit être spécialisée ou adaptée.

b. Diagramme état- transitions

Permet de décrire sous forme de machine à états finis le

comportement du système ou de ses composants.

c. Diagramme d’activité

Permet de décrire sous forme de flux ou d’enchainement d’activités

le comportement du système ou de ses composants.

 DIAGRAMME D’INTERACTION DYNAMIQUE

a. Diagramme de séquence

Représentation séquentielle du déroulement des traitements et des

interactions entre les éléments du système et/ou de ses acteurs.

b. Diagramme de communication
 51

Représentation simplifiée d’un diagramme de séquence se

concentrant sur les échanges de messages entre les objets.

c. Diagramme global d’interaction

Permet de décrire les enchainements possibles entre les scénarii

préalablement identifiés sous forme de diagramme de séquences

Dans ce travail nous ne serons pas à mesure de dresser tous les diagrammes
énoncés ci-dessus, mais nous nous concentrerons sur quelques-uns d’entre eux.

1. INSCRIPTION ET REINSCRIPTION

Diagramme de cas d’utilisation

System

Déposer le dossier

Payer la fiche de
ADMINISTRATEUR DE
scolarité
BUDGET

ETUDIANT

Payer les frais de

Réinscription
Etablir la liste
définitive

Etablir la fiche de
scolarité

COMMISSION D'INSCRIPTION

Déposer le rapport d'

inscription
 52

Diagramme de séquence