|
1
CHAPITRE I : INTRODUCTION
I.1. Mise en contexte
L'homme cherche constamment à améliorer ses
conditions de travail en maintenant un niveau élevé de production
et réduisant les efforts physiques, ce qui l'a conduit à la
création d'une nouvelle science appelé « informatique
».
La requisite de l'élite intellectuelle et son
épanouissement dans la société actuelle Dépend des
multiples facteurs qui se caractérisent par la recherche des solutions
pour l'amélioration des conditions de vie dans tous les domaines.
L'informatique est considéré comme outil
efficace de la gestion parce qu'elle se place au centre de résolution
des multiples problèmes complexes de gestion d'entreprise, grâce
à son système de traitement automatique, rapide et rationnel
d'une masse d'information par ordinateur en vue de produire des bons
résultats répondant aux besoins des utilisateurs.
Celle-ci se trouve actuellement au carrefour des autres
sciences, permet le traitement de l'information d'une manière
automatique et rationnelle, grâce à son outil appelé «
l'ordinateur ». Celui-ci devient, à ce jour, le moyen le plus
adapté pour le traitement des informations et de la communication.
Selon Roger TOMLIN, l'informatique est une science qui offre
des fonctionnements qui permettant de traiter en entrées et en sorties,
de le conserver et de les diffuser sur base de l'outil qui est l'ordinateur. En
effet devant une masse importante d'informations à traiter se traduit le
manque de contrôle, de planification et d'administration avec
efficacité.1
Au sein des entreprises, beaucoup de tâches complexes de
gestion qui jadis étaient réalisées manuellement, sont en
ce jour informatisées pour produire des résultats fiables
répondant aux objectifs assignés. La gestion d'informations
relatives à la gestion scolaire connaît des difficultés
pour le traitement de l'information2.
Cependant, l'administration de la Complexe Scolaire la
CONFIANCE en général et celle de la gestion scolaire ne font pas
l'exception en besoin technologique de traitement de l'informatique. Notre
effort sera de mettre au point une application orienté web qui permettra
de stocker les informations utiles au système et de poser des jalons
d'une application taillée sur mesure susceptible de résoudre les
problèmes liés à la gestion de cette institution.
Au regard de ces avantages incontestables tels que la
rapidité dans la prise de
1 ROGER TOMLIN, la mise en place de l'information
dans une entreprise, Paris, Ed, d'organisation, 1972.
2 MPIA Cours MRSI (Méthode de recherche
scientifique en informatique) L1 isp Gombe 2022
3 MPIA D. ; Notes de cours de méthode de
recherche scientifique en informatique, L1 ISPG, 2020-2021. Inédites
2
décision, facilité l'accès à
l'information, la sécurité des informations ; la non
redondance; traitement des informations en temps réel,
tenant compte de la masse très élevée des informations
à traiter, la nécessité d'une base de données dans
la gestion scolaires s'avère indispensable, notre attention est
porté la mise en place d'un système d'information
informatisé qui sera conçue et réalisée en suivant
la démarche du Processus Unifié (UP, pour Unified Process) est un
processus de développement logiciel « itératif et
incrémental, centré sur l'architecture, conduit par les cas
d'utilisation et piloté par les risques
Partant de la réalité d'évolution et de
la modernité et au regard de volume des informations à traiter,
la nécessité d'un système d'information informatisé
pour la gestion des activités scolaire s'avère indispensable pour
permettre la bonne améliorer du système d'information
existant.
Ainsi, notre choix est focalisé sur « Mise en
place d'un Système d'information informatisé pour la gestion
scolaires » processus inscription des élèves, paiement de
frais afin de trouver des solutions aux difficultés
présentées.
I.2. Problématique
La problématique est un ensemble de problèmes
qu'un chercheur rencontre sur le terrain lors de ses investigations. On peut
définir une problématique comme un ensemble de
préoccupations qui expriment le but de la recherche3. Ainsi
que la problématique d'un sujet revient à soulever les
préoccupations majeures dans un sujet afin de pouvoir mieux
l'aborder.
D'après les investigations que nous avons menées
dans le cadre de notre travail, nous sommes rendu compte que le Complexe
Scolaire la CONFIANCE utilise une gestion manuelle pour gérer les
activités d'une école alors que le gain de temps est l'une des
caractéristiques d'une bonne gestion. Nous avons identifiés
quelques problèmes pose par la gestion manuelle :
· L'enregistrement manuel des informations dans des
registres qui ne sont que des papiers ;
· Mauvaise conservation des informations ;
· Travail fastidieux de recherche d'information dans les
registres en cas de besoins ;
· Difficulté de consulter la base des
données manuelle parce qu'ils en n'ont pas ;
· Les résultats de traitements sont parfois
erronés ;
· Manque d'un système d'information
informatisé pour rendre efficace cette gestion ;
· Insécurité des données
traitées au niveau de l'enregistrement ;
· La lenteur et Lourdeur dans le traitement des
informations ;
· Eventualité permanente de perte des documents
;
3
· Utilisation de méthode de gestion inefficace ;
· Le risque de rendre les mauvais services aux
élèves ;
· La perte des documents ;
· Une inscription qui exige la présence physique.
I.2.1. Objectif de la recherche
Dans le cadre de notre travail, nous voudrions concevoir un
logiciel pour la gestion scolaires qui répondra effectivement aux
besoins des utilisateurs ; en prévoyant d'avance ses
fonctionnalités (l'insertion, la mise à jour, l'édition
des états de sorties) principales ; en vérifiant qu'elle fait
bien ce qui avait été prévu ; qui présente
certaines qualités: la fiabilité, la sécurité, qui
offrira la possibilité de rechercher facilement des informations
relatives aux activités scolaires ; fournir les états de sortie
des différentes opérations en rapport au processus de gestion
scolaires ; afficher et imprimer la situation d'enregistrement scolaires ;
donner la possibilité d'insérer des informations relatives
à la gestion des immeubles dans la base de données; permettre
d'imprimer les différents rapports d'activités .
L'idéal principal de ce travail de recherche est
d'informatiser le service qui s'occupe la gestion des activités scolaire
au Complexe Scolaire la CONFIANCE
I.2.2. Question de la recherche
Tenant compte de ses faiblesses, la problématique se
résume en quelque question suivante :
· Que serait l'apport de l'outil informatique dans ladite
gestion ?
· Quelles sont les méthodes et techniques à
prendre en considération pour y arriver ?
· Comment procéder pour développer un
système information informatisé adapté à la gestion
scolaire ?
I.2.3. Hypothèse
Uns hypothèse de recherche étant une proposition
de réponse aux questions posées à la problématique
en rapport avec la recherche est formulée de sorte que l'observation et
l'analyse fournissent réponse.
C'est l'ensemble de pistes de solutions proposés aux
problèmes rencontrés au niveau de la problématique. Se
rapportant à notre sujet, nous souhaitons remplacer le système
existant par un nouveau système informatisé en vue
d'améliorer la qualité de gestion des frais scolaire et
remédier aux lacunes constatées4
Le système informatique présente les avantages
ci-après :
4 MPIA N cours MRSI (Méthode de recherche
scientifique en informatique) L1 isp Gombe 2022
4
? La fiabilité et la rapidité dans le traitement
des informations ; ? Une très bonne conservation des données.
I.3. Choix et intérêt du sujet
Le choix porté sur ce sujet dans le cadre de ce
travail, n'est pas un fait du hasard, il est motivé par l'observation de
la lourdeur, occasionnée par le traitement manuel des informations, dans
la gestion des activités scolaire.
Son intérêt a deux dimensions, qui sont :
? Pour nous, en tant qu'étudiante, ce travail de lier
la théorie à la pratique.
? Pour le Complexe Scolaire la CONFIANCE : « cette
étude peut la doter d'un logiciel capable de gérer ses
différents services et la prise en charge des activités scolaires
et de résoudre les failles trouvées sur terrain. »
I.4. Délimitation du sujet
Pour répondre aux normes scientifiques, tout travail
doit être délimité. Nous avons focalisé notre
étude dans l'espace au Complexe Scolaire la CONFIANCE plus
précisément aux processus paiement de frais et
Inscription des élèves.
I.5. Méthode et technique I.5.1.
Méthodologie
Dans le domaine scientifique ou technique une méthode
est un système où ensemble de procédés
utilisés dans le but d'obtenir un certain résulta5.
Elle est l'ensemble de procédés, des moyens organisés
rationnellement pour arriver à un résultat.
Les méthodes définissent également une
représentation, souvent de graphique qui permet d'une part de manipuler
aisément les modelés, et d'autre part de communiqués et
échanger l'information entre les différents intervenants, une
bonne représentation recherche l'équilibre entre la
densité d'information et la lisibilité6.
Pour réaliser ce travail, nous nous sommes servis des
méthodes ci-après :
? Méthode historique : elle
désigne l'ensemble de réflexion qui porte sur les
procédés, les moyens, les règles suivie et les contextes
des travaux historiques.
? Méthode structure-fonctionnelle
(structuro-fonctionnalis) : elle nous a permis de comprendre et de connaitre la
structure du Complexe Scolaire la CONFIANCE partant de son organigramme et le
fonctionnement des différents composants étudiés ;
5 Microsoft Encarta 2009.
6 MUSANGU LUKA, Méthode d'analyse
informatique 1, Kinshasa, Ed Emmanuel, 2017, p9
5
· Méthode analytique : elle nous
a permis d'analyser les faits par la décomposions de divers
éléments du système dans le but de les définir et
d'en dégager les spécificités ;
· Méthode PERT : En
français Technique d'évaluation et d'examen de projet, cette
méthode consiste à créer un réseau qui prend en
compte la chronologie des taches et leurs dépendances afin de parvenir
à l'étape finale, c'est - à dire au produit
fini7
· Méthode UP (Processus
Unifié) : Une méthode de développement pour les logiciels
orientés objets vient pour compléter la systémique des
modèles UML. Un processus définit une séquence
d'étapes, en partie ordonnées, qui concourent à
l'obtention d'un système logiciel ou à l'évolution d'un
système existant. L'objet d'un processus de développement est de
produire des logiciels de qualité qui répondent aux besoins de
leurs utilisateurs dans des temps et des coûts prévisibles ;
I.5.2. Techniques
Ce sont des moyens dont la recherche se dispose pour
récolter les informations relatives à son sujet.
Pour réaliser ce travail nous nous sommes servi les
techniques ci-après :
· Technique interview : Cette technique
nous à permit d'avoir les données de ce présent travail
à partir de jeu de question-réponse auprès de
différents utilisateurs du système étudié.
· Technique de l'observation : Elle
nous a permis de nous rendre compte du fonctionnement et du comportement du
système existant par la simple vue. Elle nous a permis de descendre sur
le terrain pour observer les procédures de gestion utilisées et
différents moyens de traitement des informations utilisés par le
service concerné par l'étude.
· Technique de documentaire : Cette
technique consiste à exploiter et consulter les ouvrages et surtout
préalablement élaborés dans le domaine mis à la
disposition du chercheur afin de récolter les données où
informations recherchées.
I.6. Subdivision du travail
Hormis la conclusion, notre travail comporte 5 chapitres
à savoir :
CHAPITRE 1 : INTRODUCTION
CHAPITRE 2 : CADRE CONCEPTUEL
CHAPITRE 3 : DEMARCHE DU PROJET
CHAPITRE 4 : ANALYSE ET CONCEPTION
CHAPITRE 5 : DEVELOPPEMENT DE L'APPLICATION
7 MAPHANA cours (Recherche Opérationnelle) L1
isp Gombe 2022
6
CHAPITRE II : CADRE CONCEPTUEL
Section 1. Notions sur le système 1.1
Définition
Un système peut être défini comme un
« ensemble d'éléments en interaction dynamique,
organisé en fonction d'un but (Joël De Rosnay in « Le
Macroscope », éditions du Seuil) ».
Un système est aussi défini comme un assemblage
d'éléments reliés entre eux compris dans un ensemble plus
grand. En latin et en grec, le mot « système » veut dire
combiner, établir, rassembler.
Ensemble d'éléments structurés et
coordonnés afin de constituer un tout scientifique, l'interaction entre
les différents éléments pouvant être, ou non,
aléatoire8.
1.2 Sortes des systèmes
Il existe plusieurs sortes des systèmes. Mais dans le
cadre de notre travail, nous pouvons citer : le système d'exploitation
qui est un Ensemble de logiciels qui tournent en permanence sur un ordinateur
et le contrôlent à partir de son démarrage (boot) et tant
que celui-ci est allumé. Ainsi que le système d'information qui
sera développé dans le point qui suit9.
1.2.1 Le système d'informatique
Le système d'informatique peut être
défini comme étant l'ensemble des moyens humains,
matérielles permettant le traitement automatique des informations, au
moyen de l'ordinateur qui en constitue l'élément central.
Le Système informatique est l'ensemble des actifs
matériels et logiciels de l'entreprise ayant pour vocation à
automatiser le traitement de l'information. C'est la partie visible à
laquelle tout le monde pense quand on parle de projets et d'infrastructures
informatiques10.
1.2.2 Qualité d'un système
d'informatique
Dans la pratique, un système d'informatique
possède les qualités suivantes :
? Rapidité ; ?
Fiabilité ;
8
https://www.e-marketing.fr/Definitions-Glossaire/Systeme-243287.htm,
consulté Dimanche 24/05/2022.
9 MIRIAN HALFELD-FERRARI : System exploitation,
(Operating Systems) Introduction, p2
10 Jacques Lonchamp : Introduction aux
systèmes informatiques (Architectures, composants, mise en oeuvre),
éd. Dunod, 2011, p1-10.
7
· Pertinence ;
· Sécurité.
1.2.3 Typologie des systèmes d'informatiques
a. Selon le degré organisation On distingue
:
· Système indépendant ;
· Système intégré.
b. Selon le degré d'automatisation On distingue
:
· Système à traitement manuel ;
· Système à traitement mécanique ou
utilisé les auxiliaires mécaniques ;
· Système à traitement automatique ou tout
travail est réalisé à l'aide d'une machine
électronique programmable (EX : Ordinateur...).
c. Selon l'architecture de traitement On distingue
:
· Système d'information centralisé ;
· Système d'information décentralisé
ou reparti ;
· Système d'information mixte (distribué)
1.2.4 Le système d'information
Un système d'information est un système
organisé de ressources, de personnes et de structures qui
évoluent dans une organisation et dont le comportement coordonné
vise à atteindre un but commun. Les systèmes d'information sont
censés aider les utilisateurs dans leurs activités : stocker et
restaurer l'information, faire des calculs, permettre une communication
efficace, ordonnancer et contrôler des tâches, etc.11
Un système d'Information (noté SI)
représente l'ensemble des éléments participant à la
gestion, au traitement, au transport et à la diffusion de l'information
au sein de l'organisation12.
11 BOUBKER SBIHI ET REDOUANE EL YAAGOUBI :
analyse et conception d'un système, d'information avec la
méthode merise : cas d'une bibliothèque universitaire,
école des sciences de l'information, Ed Paris, 18 Sep 2005, p2
12 NGANG BILOUNGA Jean Jacques : Méthode de
Conception des Systèmes d'Information, éd Eyrolles, 2000,
p4
13 Antoine Zimmermann :
Conception de Systèmes d'Information, École Nationale
Supérieure des Mines de Saint-Étienne, Pôle informatique
2013/2014, p1-6
8
Nous pouvons définir un système d'information
(SI) comme l'ensemble des ressources de l'entreprise qui permettent la gestion
de l'information. Le SI est généralement associé aux
technologies (matériel, logiciel et communication), aux processus qui
les accompagnent, et aux hommes qui les supportent. D'abord simplement
appelé informatique, cet ensemble a pris le nom de SI avec
l'arrivée des nouvelles technologies qui ont élargi son
domaine13.
1.2.5 Type des systèmes d'information
Les éléments du système sont
eux-mêmes des systèmes (ou sous-systèmes). L'entreprise
peut se décomposer en 3 sous-systèmes :
· Le système de décision ou de pilotage (SP)
;
· Le système d'information (SI) ;
· Le système opérant ou les exécutants
(SO).
Chaque système apporte des services à l'autre.
a. Le système de pilotage : (appelé
également système de décision), il a comme
activités
· Exploiter les informations qui circulent ;
· Organiser le fonctionnement du système ;
· Décider des actions à conduire sur le
système opérant ;
· Raisonner en fonction des objectifs et des politiques de
l'entreprise.
b. Système d'information qui a comme
activité :
· Générer des informations ;
· Mémoriser ;
· Diffuser ;
· Traiter.
c. Système opérant qui a pour mission
:
· Reçoit les informations émises par le
système de pilotage ;
· Se charge de réaliser les tâches qui lui
sont confiées ;
· Génère à son tour des informations
en direction du système de pilotage ;
9
? Qui peut ainsi contrôler les écarts et agir en
conséquence. Il englobe toutes les fonctions liées à
l'activité propre de l'entreprise : (Facturer les clients, régler
les salaires, gérer les stocks, etc...)14
1.2.6 Rôle d'un système d'information
Pour organiser son fonctionnement, le système a besoin de
mémoriser des informations, Pour comparer, prévoir, ...Ce
rôle est joué par le Système d'Information. Ce
système a aussi la charge de :
? Diffuser l'information ;
? Réaliser tous les traitements nécessaires au
fonctionnement du système15.
Figure 1 : Structure d'un système
a. Objectif d'un système
d'information
Les objectifs spécifiques majeurs d'un système
d'information cibles sont les suivants : améliorer le système de
collection des données économiques, financières et
sociales ; assurer l'harmonisation, la cohérence et la coordination des
systèmes et diffusion des résultats.
b. Qualité d'un système
d'information
Les qualités spécifiques d'un système
d'information sont les suivants :
? La fiabilité des données ;
? La sécurité des données
et un traitement rapide des données.
14 GUILLAUME RIVIERE : Informatisation du
Système d'Information, éd. - ESTIA 2è année -,
Dernière révision : Janvier 2017, p13
15 Idem, p17
10
Section 2. Notions sur les données a.
Définition
Une donnée c'est une information
représentée sous une forme conventionnelle, afin de pouvoir
être traitée automatiquement16.
2.1 Bases de données
a. Définition d'une base de données
(BDD)
Une base de données est un ensemble structuré et
organisé de données qui représente un système
d'informations sélectionnées de telle sorte qu'elles puissent
être consultées par des utilisateurs ou par des programmes. Ainsi,
dans une grande institution comme la Bibliothèque nationale, il s'agit
de l'ensemble formé par les références des ouvrages, des
auteurs, des éditeurs, etc. Dans une entreprise, la base de
données contient l'ensemble des données concernant les clients,
les fournisseurs, les employés, les références des
produits fabriqués... et permet d'établir des relations entre ces
différentes entités17.
Une base de données (BD ou BDD) est un ensemble
structuré de données homogènes, stocké sur un
support informatique, et permettant un accès simplifié et
sécurisé à ces données via un logiciel.
? Ensemble structuré : Les données sont
réparties dans des tables, comparables à des fichiers de
données ;
? Données homogènes : On ne "mélange" pas
par exemple des données provenant de domaines différents ;
? Stocké sur un support informatique : Une base de
données se présente comme un simple et unique fichier, même
si sa taille peut être gigantesque ;
? Accès simplifié : Les logiciels envoient des
requêtes à la base données, qui elle, renvoie les
données demandées18.
2.2 Sortes des bases de données
Depuis leur apparition, les bases de données ont connu
4 évolutions majeures. Aujourd'hui, les bases de données
relationnelle (la 3ème évolution) est le type de base
qui est le plus répandu.
16 Microsoft® Encarta® 2022.
17 Odile PAPINI : Bases de données,
éd. POLYTECH Université d'Aix-Marseille, p3-11
18
www.google.fr: Notions des Bases de
données PDF, téléchargement le 21/03/2022.
Une base de données est un ensemble d'informations
connexes stockées dans un dispositif informatique. Dans une base de
données à objets les informations sont
11
I.2.2.1. Les bases de données
hiérarchiques
Une base de données hiérarchique est une base
de données dont le système de gestion lie les
enregistrements dans une structure arborescente où chaque
enregistrement n'a qu'un seul possesseur.
Figure 2 : BDD hiérarchique
I.2.2.2. Les bases de données réseaux
Là où les bases de données
hiérarchiques déclarent forfait, les bases de données
réseau prennent le relais de façon très satisfaisante. En
permettant les relations n-n (plusieurs parents / plusieurs enfants), les bases
de données font un vrai bond en avant et permettent de mimer plus
fidèlement le monde réel. D'une structure en arbre, les bases de
données deviennent des graphes.
Figure 3 : BDD réseau
I.2.2.3. Les bases de données relationnelles
C'est le type de bases que l'on connaît et que l'on
pratique aujourd'hui. Basé sur l'algèbre relationnel, il permet
de modéliser facilement et sans grosse contraintes les systèmes
du monde réel et de créer des bases de données simples
à maintenir, à faire évoluer et indépendantes de
leur support. Dans ce type de bases de données, les données sont
organisées en tables. C'est la technologie majeure en bases de
données depuis les années 1980.
I.2.2.4. Les bases de données objet
12
regroupées sous forme d'objets : un conteneur logique
qui englobe des informations et des traitements relatifs à une chose du
monde réel. Les bases de données à objets sont mises en
oeuvre par un système de gestion de base de données objet
logiciel qui manipule le contenu de la base de données et un programme
écrit dans un langage de programmation orientée objet. Les
premiers systèmes de gestion de bases de données à objets
sont apparus dans les années 1990, en même temps que se sont
répandus les langages de programmation orientés objet.
2.3 Système de gestion de bases de données
(SGBD)
a. Définition
Un système de gestion de base de données (SGBD)
est un ensemble de programmes qui permet la gestion et l'accès à
une base de données. Il héberge généralement
plusieurs bases de données, qui sont destinées à des
logiciels ou des thématiques différentes.
Le Système de gestion de base de données (SGBD)
est un logiciel permettant de couvrir les besoins : définir une
représentation des informations apte à stocker, interroger et
manipuler (insérer, supprimer, mettre à jour) de grandes
quantités de données (plus que la mémoire vive) dont il
faut garantir la longévité et l'accessibilité de
manière concurrente (plusieurs utilisateurs simultanés) et
sûre19.
Figure 4 : SGBD
b. Les SGBD les plus utilisés
Voici ci-dessous un tableau présentant le classement
des SGBD les plus populaires pour l'année 2014. Ce classement a
été produit par Solid IT une firme qui a fait de du classement
des SGBD son domaine d'expertise20.
Tableau 1 : Les SGBD les plus
utilisés
|
Rang
|
SGBD
|
Modèle de BDD
|
Cotation
|
Changes
|
|
1
|
Oracle
|
SGBD relationnel
|
1467,79
|
-0,26
|
|
2
|
MySQL
|
SGBD relationnel
|
1296,91
|
-12,38
|
|
3
|
Microsoft SQL Server
|
SGBD relationnel
|
1226,02
|
20,14
|
19
www.google.fr: Introduction aux
bases de données PDF, télécharger le 29/01/2022, p12
20
www.wikipedia.org: Liste des
SGBD les plus utilisés le 21/03/2022.
13
|
4
|
PostgreSQL
|
SGBD relationnel
|
228,25
|
-2,71
|
|
5
|
DB2
|
SGBD relationnel
|
188,31
|
-2,3
|
|
6
|
MongoDB
|
Document store
|
178,23
|
-4,84
|
|
7
|
Microsoft Access
|
SGBD relationnel
|
174,99
|
3,32
|
|
8
|
SQLite
|
SGBD relationnel
|
97,3
|
-2,2
|
|
9
|
Sybase
|
SGBD relationnel
|
94,51
|
-0,77
|
|
10
|
Cassandra
|
Wide column store
|
81,18
|
0,67
|
2.4 Objectif d'un système de gestion de bases de
données (SGBD)
Les principaux objectifs fixés aux SGBD afin de
résoudre les problèmes causés par une gestion sous forme
de fichiers à plat sont les suivants :
· Indépendance physique : La façon dont
les données sont définies doit être indépendante des
structures de stockage utilisées ;
· Indépendance logique : Un même ensemble
de données peut être vu différemment par des utilisateurs
différents. Toutes ces visions personnelles des données doivent
être intégrées dans une vision globale ;
· Accès aux données : L'accès aux
données se fait par l'intermédiaire d'un Langage de programmation
;
· Manipulation de Données (LMD). Il est crucial
que ce langage permette d'obtenir des réponses aux requêtes en un
temps « raisonnable ». Le LMD doit donc être optimisé,
minimiser le nombre d'accès disques, et tout cela de façon
totalement transparente pour l'utilisateur ;
· Administration centralisée des données
(intégration) : Toutes les données doivent être
centralisées dans un réservoir unique commun à toutes les
applications. En effet, des visions différentes des données
(entre autres) se résolvent plus facilement si les données sont
administrées de façon centralisée ;
· Non redondance des données : Afin
d'éviter les problèmes lors des mises à jour, chaque
donnée ne doit être présente qu'une seule fois dans la base
;
· Cohérence des données : Les
données sont soumises à un certain nombre de contraintes
d'intégrité qui définissent un état cohérent
de la base. Elles doivent pouvoir être exprimées simplement et
vérifiées automatiquement à chaque insertion, modification
ou suppression des données. Les contraintes d'intégrité
sont décrites dans le Langage de Description de Données (LDD)
;
· Partage des données : Il s'agit de permettre
à plusieurs utilisateurs d'accéder aux mêmes données
au même moment de manière transparente ;
· Sécurité des données : Les
données doivent pouvoir être protégées contre les
accès non autorisés. Pour cela, il faut pouvoir associer à
chaque utilisateur des droits d'accès aux données.
14
CHAPITRE III. DEMARCHE DU PROJET
Section 1 : Cadre d'étude
La présentation de notre cadre d'investigation va porter
essentiellement sur :
1. Situation Géographique Complexe Scolaire LA CONFIANCE
;
2. Présentation de l'école
3. Brève historique du Complexe Scolaire LA CONFIANCE
;
4. Structure et fonctionnement du complexe LA CONFIANCE et ;
5. L'Organigramme du Complexe Scolaire LA CONFIANCE.
1.1. Structure Géographique du Complexe Scolaire LA
CONFIANCE
Le Complexe Scolaire LA CONFIANCE se trouve au croisement des
avenues victoires et centrale N°28/30, dans le quartier Kauka de la
commune de Kalamu.
Kauka est l'un de 8 quartiers qui composent la commune de
kalamu.il est situé à
côté du quartier Matonge » et séparé par la
rivière Kalamu. Le quartier est séparé par limite par
l'avenue université.
Donc, le complexe scolaire LA CONFIANCE est à deux cents
mètres au rondpoint victoire.
1.2. Présentation de l'école
Complexe scolaire la Confiance est une Ecole privée
conventionnée Catholique, elle a les maternelles, primaire, secondaire
générale fonctionne les avant-midis, et les humanités
générale les après-midi. L'Ecole a plusieurs option telle
que :
? Option Commerciale et gestion ;
? Option Chimie biologie ;
? Option Pédagogie générale ;
? Option la coupe et couture ;
? Et l'électricité générale.
1.3. Brève historique du Complexe Scolaire la
CONFIANCE
L'initiative de la création du complexe scolaire la
confiance revient à l'abbé SHANGA MAPANGU Julien, curé de
la mission catholique de KABUANGA au Kasaï occidentale et
représentant de GMPV don de Luciano d'Italie en RDC.
L'idée de la création de cette école remonte
à l'an 2017, une structure devant perpétuer l'esprit
perfectionniste (souci du travail bien fait), élitiste (souci d'exceller
à tous égards) et humaniste (l'humilité, l'amour du
prochain, le partage...).
15
Abbé MAPANGU Julien aimait beaucoup les enfants et
surtout les enfantant abandonnés, délaissés à leur
triste sort, cette idée fut matérialisée par la conception
et rédaction des statuts et règlements d'ordre intérieur
de l'école.
De ce fait, l'école fut agréée par le
ministère de l'enseignement primaire, secondaire et professionnelle sous
le n°MINEPSP /CABMIN/2545/2018 du 21/O8/2018 autorisant l'organisation et
le fonctionnement des sections maternelle, primaire, secondaire
général et les humanités : littéraire
chimie-biologie, pédagogie générale commerciale gestion,
coupe et couture, électricité, mécanique...
Monsieur l'abbé est promoteur et président du
conseil d'administration :
Au cours de la première année, le CS la
CONFIANCE est composé d'une équipe dirigeante dont :
> Monsieur JEAN-PIERRE BOYEKE : préfet des
études
> Mr THEOPHILE B ISIMA : directeur des études
> Mr JEAN-PIERRE PIMPA MFUDI : conseiller
pédagogique
> Mademoiselle LA B LONDE B OYEKE : secrétaire
> Mademoiselle LOURDES LOFOSO : chargée de finances
> Mr OWUNDO MUNONGO : chargé de discipline
> KILOLA MAYEME : intendante
Identification de Complexe Scolaire LA
CONFIANCE
Dénomination : Complexe Scolaire LA CONFIANCE
N° d'agrément : MINEPSP/CABMIN/2545/2018 AU
21/08/2018
N° matricule : 4/11.306/5202
Identité SECOPE : 101030478
Niveau : Secondaire
Options : Littéraire, chimie-biologie, Pédagogie
générale,
Commerciale gestion, Coupe et couture, Electricité,
Mécanique...
Régime de Gestion : Convention Catholique
Adresse : 28/30 Centrale C/ Kalamu District / FUNA
Province/ KINSHASA Adresse Postale : B.P. 5643 Kinshasa
16
1.4. Structure et fonctionnement du Complexe Scolaire LA
CONFIANCE
1.4.1. Préfecture
La préfecture est dirigée par le préfet des
études et chef d'Etablissement Mr Jean Marie MUNZOBE pratiquement en
fonction depuis 2015.
Les Attributions du Préfet
Le préfet est chargé de la gestion courante de
l'école. A ce titre, il a pour mission de :
· Coordonné toutes les activités tant
pédagogiques qu'administrative de l'école ;
· Veiller à l'application des directives du
ministère de la tutelle ;
· Arrêter toutes les mesures nécessaires au
bon fonctionnement de l'école ;
· Gérer les personnels enseignants et administratifs
;
· Contrôler et superviser toutes les activités
et faire rapport à la hiérarchie.
1.4.2. La Direction des Etudes
Elle est dirigée par le directeur des Etudes qui est
Mr Jean Marie MUNZOBE, il est le 15 adjoint du préfet, il le remplace en
cas d'absence ou d'empêchement. Il a pour empressement de :
· Gérer le personnel enseignant ;
· Visiter les professeurs et contrôler leurs
documents pédagogiques ;
· Elaborer les horaires des cours et d'examens ;
· Distribuer et carder les fournitures scolaires et les
matériels didactiques de l'école.
1.4.3. La Direction de Discipline
Elle est dirigée par un Directeur de discipline, qui
est le collaborateur du préfet en matière de Discipline, il a
comme attribution :
Elle s'occupe de l'ordre au niveau des élèves ;
Il assure la propriété de la cour de
l'école et des salles des classes ;
· Il statut et renvoi temporairement les
élèves indisciplinés après avertissements des
parents.
1.4.4. Le secrétariat
Le secrétaire est le collaborateur du préfet, il
s'occupe de :
· La tenue des dossiers administratifs ;
· La correspondance ;
17
? La réception de visiteurs ;
? L'organisation et la supervision des activités des
membres du secrétariat :
? Elle s'occupe également de la tenue du registre
matricule et des dossiers des enseignent et élèves ;
1.4.5. Intendance
L'intendant est responsable des activités des membres
du patrimoine matériel et financier de l'Etablissement. Elle est
financière de l'école, elle collecte des frais scolaires et
exécute toutes les dépenses relatives aux bons fonctionnements de
l'école, suivants les ordres du chef d'établissements.
1.4.6. Corps professoral
C'est l'ensemble de tout ce qui assure l'enseignement
auprès des élèves dans les salles de classes. Chacun selon
sa discipline de formation, ils organisent les cours, les devoirs et les
interrogations, ils proposent des questions pour les différentes
sessions de l'examen, ils calculent les côtes des
élèves.
1.4.7. Les travailleurs
Ils tiennent la propriété de l'école et
exécute d'autre taches selon les besoins de l'école.
18
1.5. Organigramme générale du COMPLEXE
SCOLAIRE LA CONFIANCE
PROMOTEUR
PREFET DES ETUDES
DIRECTION DES ETUDES
SECRETARIAT
DIRECTION DES ETUDES
ELEVES
Figure 5 : La représentation du réseau
PERT Source : Secrétariat
PROFESSEURS
PROFESSEURS
CONSEILLER PEDAGOGIQUE
|
CONSEILLER PEDAGOGIQUE
|
|
|
|
|
|
|
19
Section 2 : Méthode conceptuel projet
Ce chapitre constitue l'étape importante du projet. Il
s'agit en effet de s'interroger sur les possibilités de
réalisation du projet, en termes de produits, rendement, ressources,
compétences, capacité de financement et risques induits. La phase
d'étude de faisabilité vise à apporter les
éléments pertinents qui devront convaincre les décideurs
à approuver le projet et ordonner sa mise en oeuvre. La
faisabilité opérationnelle s'occupe de cadrage de projet
d'information, il est question ici de s'appuyer sur le cours de Recherche
Opérationnelle (R.O) pour faire un planning prévisionnel de
réalisation de projet, identifier le chemin critique et
déterminer les dates la plus tard et plutôt pour la finalisation
de projet.
Il est défini comme un groupement d'acteur des
ressources en vue de réaliser des objectifs dans un détail par
moyens prévenus en faisant appel ou nom à des moyens
extérieurs, un projet est désigné à être
planifié dans le but de pouvoir le maitriser et de réaliser dans
les conditions des coûts et de détails de imposes, en
vérifiant inlassablement si le plan établi (aspects
économiques et administratifs) a pour but le suivi et la rationalisation
des offerts de développement en maitrisant les coût et
détail, l'organisation et la visualisation des taches et ressources du
projet, l'affichage des écarts aux provisions21.
2.1. Faisabilité
opérationnelle
Dans l'étude de faisabilité
opérationnelle, il sera question de définir la manière
dont le projet sera développé en tenant compte des contraintes de
temps et financières. Pour ce faire un recours aux notions de recherches
opérationnelles nous ai indispensable.
2.1.1. Planning prévisionnelle
La planification du projet est initialisée au
début d'un projet et mise à jour pendant toute une durée
de la vie. Un même projet peut faire l'objet de plusieurs plannings. Par
définition un projet est un ensemble d'opérations
présentant une certaine unicité qui doivent permettre à
atteindre un objectif clairement exprimable22.
L'ensemble de ces plannings permet de gérer les
principales tâches et jalons du projet. Un projet comporte toujours un
nombre de tâches plus ou moins grand à réaliser dans les
détails impartis et selon un agencement bien déterminé. Le
diagramme de GANTT, PERT et MPM sont des outils permettant de planifier le
projet et de rendre plus simple le suivi de son avancement. Pour que l'objectif
fixé dans un projet soit atteint, il faut qu'un certain nombre des
opérations soient effectués. Nous parlons ici
21 MAPHANA ma NGUMA, Notes de cours de recherche
opérationnel, ISS, année 2011-2012, inédites
22 MUSANGU LUKA Marcel, Notes de cours inédits
de la Conception des Systèmes d'Information, L2, ISC, 2021,
inédites
20
des tâches ou activités.
Aussi, l'accomplissement d'un projet demande un certain
nombre des conditions :
· Une parfaite connaissance d'articulation des tâches
du projet ;
· L'établissement d'un plan complet d'action
permettant de réaliser les conditions de coût et le délai
imposé ;
· Pendant son déroulement, vérifier
constamment si le plan établi est respecté en cause
d'écart observé, ou cherché à le réduire.
2.1.2. Choix de la méthode d'ordonnancement
L'ordonnancement permet d'organiser un planning optimal des
taches, mais également d'indiquer celles des tâches qui peuvent
souffrir de retard sans compromettre la durée totale du projet. Ses
tâches doivent respecter certaines contraintes qui peuvent être
soit :
· Soit des contraintes d'antériorité : une
tâche B ne peut commencer que lorsque la tâche A est
terminée (contrainte de succession) ;
· Soit des contraintes de date : une tâche ne peut
commencer avant une certaine date.
· L'objectif est de minimiser la durée totale de
réalisation de chacune des opérations et des contraintes qu'elles
doivent respecter.
· Il existe plusieurs méthodes d'ordonnancement.
Pour la planification et la réalisation de notre travail nous avons
choisis :
· La méthode à diagramme (Le Diagramme de
GANTT) ;
· Les méthodes à chemin critique (PERT,
MPM, CPM).
La méthode que nous utilisons pour
l'élaboration de ce planning est la méthode PERT, et la
construction d'un graphe PERT début par la définition des
tâches nécessaires pour réaliser le projet la valeur arc
sera durée dj de la tâche i. Le début et la fin d'une
étape sont les étapes fines du projet. On définit une
étape début du projet, une étape et un certain nombre
d'étapes intermédiaires. Si une tâche j succède
à une tâche i, il faudra que l'extrémité de l'arc
uj l'extrémité final et l'arc ui
correspondant à la tâche i.
La méthode PERT se décompose selon les
étapes suivantes :
· Lister des tâches d'une manière exhaustive
;
· Estimer la durée de chaque tâche ;
· Tracer le réseau PERT ;
· Déterminer les dates au plut tôt ;
· Déterminer les dates au plus tard,
21
? En déduire le chemin critique ; ? Calculer les marges
libres ; ? Calculer les marges totales ; ? Diagramme de GANTT.
2.1.3. Identification et dénombrement des
tâches
Ce point consistera à présenter un tableau en
suivant l'ordre chronique de différentes tâches du projet et faire
l'estimation de durée en temps du dite projet.
Tableau 2 : Identification et dénombrement des
tâches
Code
|
Désignation
|
Durée
|
A
|
Contact préliminaire & Visite de l'entreprise
|
---
|
B
|
Récolte de données
|
A
|
C
|
Analyse & Capture de besoin
|
B
|
D
|
Présentation de l'architecture
|
C
|
E
|
Elaboration de système
|
D
|
F
|
Construction de système
|
E
|
G
|
Achat & Acquisition des matériels
|
F
|
H
|
Installation
|
G
|
I
|
Configuration et sécurisation des matériels
|
H
|
J
|
Test
|
I
|
K
|
Transition
|
J
|
L
|
Elaboration (rédaction) de manuel des
procédures
|
K
|
M
|
Formation des utilisateurs
|
L
|
N
|
Observation du réseau mise en place
|
M
|
|
2.1.4. Planning d'exécution des taches et
estimation des durés
Tableau 3 : Planning d'exécution des
tâches.
N°
|
TACHES
|
LIBELLE
|
TACHES
ANTERIEUR
|
DURE/
JOUR
|
1
|
A
|
Contact préliminaire & Visite de
l'entreprise
|
---
|
3
|
2
|
B
|
Récolte de données
|
A
|
10
|
3
|
C
|
Analyse & Capture de besoin
|
B
|
14
|
4
|
D
|
Présentation de l'architecture
|
C
|
9
|
5
|
E
|
Elaboration de système
|
D
|
21
|
6
|
F
|
Construction de système
|
E
|
14
|
7
|
G
|
Achat & Acquisition des matériels
|
F
|
3
|
8
|
H
|
Installation
|
G
|
3
|
9
|
I
|
Configuration et sécurisation des matériels
|
H
|
4
|
|
22
10
|
J
|
Test
|
I
|
6
|
11
|
K
|
Transition
|
J
|
9
|
12
|
J
|
Elaboration (rédaction) de manuel des
procédures
|
K
|
9
|
13
|
M
|
Formation des utilisateurs
|
L
|
14
|
14
|
N
|
Observation du réseau mise en place
|
M
|
1
|
|
|
Total
|
|
120
|
|
2.1.5. Cucul des ranges
Rn est le nombre d'étape maximal
Rn -1[15]=R14
Rn -2[14]=R13
Rn -3[13]=R12
Rn -4[12]=R11
Rn -5[11]=R10
Rn -6[10]=R9
Rn -7[9]=R8
Rn -8[8]=R7
Rn -9[7]=R6
Rn -10[6]=R5
Rn -11[5]=R4
Rn -12[4]=R3
Rn -13[3]=R2
Rn -14[2]=R1
Rn -15[1]=R15
R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 15
2.1.6. Calcul des dates a. Date au plus tôt
(Dto)
La date au plus tôt (Dto) est la date la plus
rapprochée à laquelle il est possible de réaliser une
étape. Elle se calcule par la formule suivante : Dto(x)=Max
{Dto(y)+d(i)}. Dto(x) est considéré comme 2è étape.
Dto(y) est considéré comme 1ère étape et i comme
une tâche.
Calcul :
Dto (1)=0
Dto (2)=Dto(1)+d(A)=0+3=3 Dto (3)=Dto(2)+d(B)=3+10=13 Dto
(4)=Dto(3)+d(C)=13+14=27
23
Dto (5)=Dto(4)+d(D)=27+9=36
Dto (6)=Dto(5)+d(E)=36+21=57
Dto (7)=Dto(6)+d(H)=57+14=71
Dto (8)=Dto(7)+d(G)=71+3=74
Dto (9)=Dto(8)+d(H)=73+3=77
Dto (10)=Dto(9)+d(I)=77+4=81
Dto (11)=Dto(10)+d(J)=81+6=87
Dto (12)=Dto(11)+d(K)=87+9=96
Dto (13)=Dto(12)+d(L)=96+9=105
Dto (14)=Dto(13)+d(M)=105+14=199
Dto (15)=Dto(14)+d(N)=119+1=120
b. Date au plus tard (Dta)
C'est la date à laquelle il faut impérativement
démarrer la tâche X si on veut terminer absolument le projet dans
sa durée minimale. Sa formule est : Dta(y)=Min
Dta(x)-d(i).
Calcul :
Dta (10) =120
Dta (14)=dta(1)-d(N)=120-1=119
Dta (13)=dta(14)-d(M)=119-14=105
Dta (12)=dta(13)-d(L)=105-9=96
Dta (11)=dta(12)-d(K)=96-9=87
Dta (10)=dta(11)-d(J)=87-6=81
Dta (9)=dta(10)-d(I)=81-4=77
Dta (8)=dta(9)-d(H)=77-3=74
Dta (7)=dta(8)-d(G)=74-3=71
Dta (6)=dta(7)-d(F)=71-14=57
Dta (5)=dta(6)-d(E)=57-21=36
Dta (4)=dta(5)-d(D)=36-9=27
Dta (3)=dta(4)-d(C)=27-14=13
Dta (2)=dta(3)-d(B)=13-10=3
Dta (1)=dta(2)-d(A)=3-3=0
2.1.7. Détermination des marges
Il y a deux types des marges qui sont la marge totale et la
marge libre.
? Marge libre : Elle est le délai de
la mise en route de la tâche (i) sans compromettre la Dto de
l'étape (y). Elle se calcule par la formule : ML(i)=Dto(y)-d(i).
Sur base de cette formule que nous allons chercher les marges libres
de nos tâches.
La tâche x sera une tâche critique si et
seulement si Txt=Tx c'est-à-dire qu'une tâche critique est une
tâche dont la date de début au plus tôt correspond à
la date de
24
Calcul :
ML(A)=Dto(2)-Dto(1)-d(A)=3-0-3=0 tâche critique
ML(B)=Dto(3)-Dto(2)-d(B)=13-3-10=0 tâche critique
ML(C)=Dto(4)-Dto(3)-d(C)=27-13-14=0 tâche critique
ML(D)=Dto(5)-Dto(4)-d(D)=36-27-9=0 tâche critique
ML(E)=Dto(6)-Dto(5)-d(E)=57-36-21=0 tâche critique
ML(F)=Dto(7)-Dto(6)-d(F)=71-57-14=0 tâche critique
ML(G)=Dto(8)-Dto(7)-d(G)=74-71-3=0 tâche critique
ML(H)=Dto(9)-Dto(8)-d(H)=77-74-3=0 tâche critique
ML(I)=Dto(10)-Dto(9)-d(I)=81-77-4=0 tâche critique
ML(J)=Dto(11)-Dto(10)-d(J)=87-81-6=0 tâche critique
ML(K)=Dto(12)-Dto(11)-d(K)=96-87-9=0 tâche critique
ML(L)=Dto(13)-Dto(12)-d(L)=105-96-9=0 tâche critique
ML(M)=Dto(14)-Dto(13)-d(M)=119-105-14=0 tâche critique
ML(N)=Dto(15)-Dto(14)-d(N)=120-119-1=0 tâche critique
? Marge totale : On appelle mage totale,
notée MT(i) le délai que nous avons disposé pour la mise
en route de la tâche (i) sans modifier la Dta de l'étape (y) (x)
étant le sommet initial de la tâche (i) et y son sommet terminal.
Sa formule est : MT(i)=dta(y)-dto(x)-d(i).dta(y) est le sommet
terminal, dto(x) est le sommet initial.
Calcul :
MT(A)=Dto(2)-Dto(1)-d(A)=3-0-3=0 tâche critique
MT(B)=Dto(3)-Dto(2)-d(B)=13-3-10=0 tâche critique
MT(C)=Dto(4)-Dto(3)-d(C)=27-13-14=0 tâche critique
MT(D)=Dto(5)-Dto(4)-d(D)=36-27-9=0 tâche critique
MT(E)=Dto(6)-Dto(5)-d(E)=57-36-21=0 tâche critique
MT(F)=Dto(7)-Dto(6)-d(F)=71-57-14=0 tâche critique
MT(G)=Dto(8)-Dto(7)-d(G)=74-71-3=0 tâche critique
MT(H)=Dto(9)-Dto(8)-d(H)=77-74-3=0 tâche critique
MT(I)=Dto(10)-Dto(9)-d(I)=81-77-4=0 tâche critique
MT(J)=Dto(11)-Dto(10)-d(J)=87-81-6=0 tâche critique
MT(K)=Dto(12)-Dto(11)-d(K)=96-87-9=0 tâche critique
MT(L)=Dto(13)-Dto(12)-d(L)=105-96-9=0 tâche critique
MT(M)=Dto(14)-Dto(13)-d(M)=119-105-14=0 tâche critique
MT(N)=Dto(15)-Dto(14)-d(N)=120-119-1=0 tâche critique
2.1.8. Détermination de chemin critique.
25
début au plus tard. On appelle chemin critique, un
chemin passant par les tâches critiques.
Le chemin critique est : A, B, C, D, E, F, G, H, I, J,
K, L, M, N. a. Présentation de graphe avec la méthode
MPM
Formalisme :
? X : est le sommet qui désigne le nom
de la tâche ? TX : désigne la date du
début de la tâche x ;
? TX' : désigne la date au plus tard de
la tâche x.
NOTE : L'intervalle (Tx, Tx') se nomme
intervalle de flottement pour la tâche x.
Pour tracer le graphe potentiel, autres les
éléments cités, on doit introduire une tâche
supplémentaire qui n'est pas représenter dans le dictionnaire de
précédent z. c'est une tâche reliée à tous
les sommets qui n'ont pas de successeurs cela veut- dire, somme suivant cette
tâche permettra de dater la fin de travaux.
26
3 H
0
0
3
3 3
10
13 13
14
27 27
9
36 36
21
57 57
14
71 71
3
74 74
A
2
B
3
C
D
5
E
6
F
7
G
8
77 77
4
81 81
6
87 87
9 96 96
9 105 105
14
119 119
1 120 120
9
I
10
J
11 K
12
L
13
M
14
N
15
Figure 5 : La représentation du réseau
PERT
27
b. Diagramme de GANTT
Le Diagramme de Gantt a été mis au point par
Henry Gantt de Nationalité Américaine. Pour ce type de Diagramme
on présente au sein d'un tableau, en ligne, les différentes
tâche et colonne les unités de temps (exprimées en mois,
semaine, jours, heures, etc....). La durée d'exécution d'une
tâche est matérialisée par un trait au sein du
diagramme.
Réalisation Les différentes étapes de
réalisation d'un diagramme de Gantt sont les suivantes :
? On détermine les différentes tâche (ou
opérations) à réalisation et leur durée ;
? On définit les relations d'antériorités
entre les taches ;
? On présente d'abord les tâches n'ayant aucunes
antériorités, puis les tâches dont les tâches dont
les taches antérieures ont déjà été
présentées, et ainsi de suite ;
? On présente par un trait parallèle en
pointille à la tache planifiée par progression réelle du
travail.
Figure 7 : Diagramme de GANT
2.2. Faisabilité financière
Pour remplir un besoin logiciel il peut exister de multiples
possibilités : développement d'un logiciel spécifique,
adaptation d'un logiciel existant, utilisation d'un progiciel... Les travaux de
la phase de faisabilité consistent à examiner tous ces types de
solution pour voir si elles sont faisables et si elles permettent de remplir le
besoin, et évaluer leur coût. Les solutions peuvent avoir des
coûts très différents pour l'acquisition, mais aussi pour
l'utilisation. On fera donc les comparaisons de coût global de
possession,
28
somme des coûts d'acquisition et des coûts
d'exploitation, maintenance et maintien à niveau sur la durée
prévue d'utilisation.
Tableau 4 : Faisabilité
financière
N°
|
Tâches
|
Nombres
de jours
|
Coûts
journaliers en $
|
Coût total en
$
|
1
|
Contact préliminaire & Visite de
l'entreprise
|
3
|
10$
|
30$
|
2
|
Récolte de données
|
5
|
10$
|
50$
|
3
|
Analyse & Capture de besoin
|
14
|
40$
|
560$
|
4
|
Présentation de l'architecture
|
9
|
200$
|
1.800$
|
5
|
Elaboration de système
|
21
|
45$
|
945$
|
6
|
Construction de système
|
14
|
100$
|
1.400$
|
7
|
Achat & Acquisition des matériels
|
3
|
700$
|
2.100$
|
8
|
Installation
|
3
|
50$
|
150$
|
9
|
Configuration et sécurisation des
matériels
|
4
|
50$
|
200$
|
10
|
Test
|
6
|
90
|
540$
|
11
|
Transition
|
9
|
100$
|
900$
|
12
|
Elaboration (rédaction) de manuel des
procédures
|
9
|
30$
|
270$
|
13
|
Formation des utilisateurs
|
14
|
10$
|
140$
|
14
|
Observation du réseau mise en place
|
1
|
100$
|
100$
|
15
|
Imprévus
|
215$
|
|
TOTAL
|
125 jours
|
|
9.400$
|
|
29
Section 3. Notions sur la méthode processus
unifié (UP)
Pendant plusieurs décennies, le monde Informatique a
toujours rêvé d'un processus qui puisse garantir le
développement efficace de logiciels de qualité, valable quelques
soit la grandeur et la complexité du projet, présentant de bonnes
pratiques adaptées à la méthode en question, surtout que,
de nos jours, les logiciels demandés sont de plus en plus imposants et
exigeants qu'auparavant.
Le processus Unifié semble être la solution
idéale pour remédier à l'éternel problème
des développeurs. En effet, il regroupe les activités à
mener pour transformer les besoins d'un utilisateur en un système
logiciel quel que soit la classe, la taille et le domaine d'application de ce
système.
Il utilise le langage UML (Unified Modeling Language). Ce
langage de modélisation est une partie intégrante du processus
unifié, ils ont été d'ailleurs développés de
concret.
3.1 Définitions
Le processus unifié est un processus de
développement logiciel : il regroupe les activités à mener
pour transformer les besoins d'un utilisateur en système logiciel.
Le processus unifié PU, ou UP (anglais : unified
process) est une méthode de développement pour les logiciels
orientés objets. C'est une méthode générique,
itérative et incrémentale, contrairement à la
méthode séquentielle Merise.
Le processus unifié est un processus de
développement moderne, itératif, efficace sur des projets
informatiques de toutes tailles. Très complet, il couvre l'ensemble des
activités, depuis la conception du projet jusqu'à la livraison de
la solution. Intégrant une organisation de projet type, une
méthodologie utilisant UML et un ensemble de bonnes pratiques
cohérentes entre elles, il permet de circonvenir aux problèmes
récurrents que rencontrent nombre de réalisations : dérive
des coûts et des délais, qualité insuffisante,
réponse incomplète aux attentes des utilisateurs. Un point
d'excellence de cette démarche est son adaptabilité.
C'est un patron de processus pouvant être
adaptée à une large classe de systèmes logiciels, à
différents domaines d'application, à différents types
d'entreprises, à différents niveaux de compétences et
à différentes tailles de l'entreprise.
Caractéristiques essentielles du processus unifié
:
? Le processus unifié est à base de composants,
? Le processus unifié utilise le langage UML (ensemble
d'outils et de diagramme), ? Le processus unifié est piloté par
les cas d'utilisation,
30
? Centré sur l'architecture, ? Itératif et
incrémental.
Les adaptations d'UP les plus connues sont :
? RUP : Rational Unified Process
? XP : eXtreme Programming ;
? 2TUP: Two Tracks Unified Process
3.2 UP est piloté par les cas d'utilisation 3.2.1
Présentation
L'objectif principal d'un système logiciel est de
rendre service à ses utilisateurs ; il faut par conséquent bien
comprendre les désirs et les besoins des futurs utilisateurs. Le
processus de développement sera donc centré sur l'utilisateur. Le
terme utilisateur ne désigne pas seulement les utilisateurs humains mais
également les autres systèmes. L'utilisateur représente
donc une personne ou une chose dialoguant avec le système en cours de
développement.
Figure 8 : Cas d'utilisation
Les cas d'utilisation permettent d'illustrer les besoins. Ils
détectent puis décrivent les besoins fonctionnels (du point de
vue de l'utilisateur), et leur ensemble constitue le modèle de cas
d'utilisation qui dicte les fonctionnalités complètes du
système.
3.2.2 Stratégie des cas d'utilisation
:
Que doit pouvoir faire le système pour chaque utilisateur
?
Les cas d'utilisation ne sont pas un simple outil de
spécification des besoins du système. Ils vont
complètement guider le processus de développement à
travers l'utilisation de modèles basés sur l'utilisation du
langage UML
31
Figure 9 : Stratégie Cas
d'utilisation
> A partir du modèle des cas d'utilisation, les
développeurs créent une série de modèles de
conception et d'implémentation réalisant les cas d'utilisation
;
> Chacun des modèles successifs est ensuite
révisé pour en contrôler la conformité par rapport
au modèle des cas d'utilisation ;
> Enfin, les testeurs testent l'implémentation pour
s'assurer que les composants du modèle d'implémentation mettent
correctement en oeuvre les cas d'utilisation.
Les cas d'utilisation garantissent la cohérence du
processus de développement du système. S'il est vrais que les cas
d'utilisation guident le processus de développement, ils ne sont pas
sélectionnés de façon isolée, mais doivent
absolument être développés "en tandem" avec l'architecture
du système.
3.2.3 UP est centré sur l'architecture
Dès le démarrage du processus, on aura une vue
sur l'architecture à mettre en place. L'architecture d'un système
logiciel peut être décrite comme les différentes vues du
système qui doit être construit. L'architecture logicielle
équivaut aux aspects statiques et dynamiques les plus significatifs du
système. L'architecture émerge des besoins de l'entreprise, tels
qu'ils sont exprimés par les utilisateurs et autres intervenants et tels
qu'ils sont reflétés par les cas d'utilisation.
Elle subit également l'influence d'autres facteurs :
> La plate-forme sur laquelle devra s'exécuter le
système ;
> Les briques de bases réutilisables disponibles pour
le développement ;
> Les considérations de déploiement, les
systèmes existants et les besoins non fonctionnels (performance,
fiabilité...).
32
3.2.4 Liens entre cas d'utilisation et architecture
Tout produit est à la fois forme et fonction. Les cas
d'utilisation doivent une fois réalisés, trouver leur place dans
l'architecture. L'architecture doit prévoir la réalisation de
tous les cas d'utilisation. L'architecture et les cas d'utilisation doivent
évoluer de façon concomitante.
3.2.4.1 Marche à suivre
? L'architecte crée une
ébauche grossière de l'architecture, en partant de l'aspect qui
n'est pas propre aux cas d'utilisation (plateforme...). Bien que cette partie
de l'architecture soit indépendante des cas d'utilisation. L'architecte
doit avoir une compréhension globale de ceux-ci avant d'en esquisser
l'architecture ;
? Il travaille ensuite, sur un sous ensemble
des cas d'utilisations identifiés, ceux qui représentent les
fonctions essentielles du système en cours de développement ;
? L'architecture se dévoile peu
à peu, au rythme de la spécification et de la maturation des cas
d'utilisation, qui favorisent, à leur tour, le développement d'un
nombre croissant de cas d'utilisation. Ce processus se poursuit jusqu'à
ce que l'architecture soit jugée stable.
3.2.4.2 UP est itératif et incrémental
Le développement d'un produit logiciel destiné
à la commercialisation est une vaste entreprise qui peut
s'étendre sur plusieurs mois. On ne va pas tout développer d'un
coup. On peut découper le travail en plusieurs parties qui sont autant
de mini projets. Chacun d'entre eux représentant une itération
qui donne lieu à un incrément.
Une itération désigne la succession des
étapes de l'enchaînement d'activités, tandis qu'un
incrément correspond à une avancée dans les
différents stades de développement.
Le choix de ce qui doit être implémenté
au cours d'une itération repose sur deux facteurs :
? Une itération prend en compte un
certain nombre de cas d'utilisation qui ensemble, améliorent
l'utilisabilité du produit à un certain stade de
développement.
? L'itération traite en priorité
les risques majeurs.
Un incrément constitue souvent un additif.
A chaque itération, les développeurs
identifient et spécifient les cas d'utilisations pertinents,
créent une conception en se laissant guider par l'architecture choisie,
implémentent cette conception sous forme de composants et vérifie
que ceux-
33
ci sont conformes aux cas d'utilisation. Dès qu'une
itération répond aux objectifs fixés le
développement passe à l'itération suivante.
Pour rentabiliser le développement il faut
sélectionner les itérations nécessaires pour atteindre les
objectifs du projet. Ces itérations devront se succéder dans un
ordre logique. Un projet réussi suivra un déroulement direct,
établi dès le début par les développeurs et dont
ils ne s'éloigneront que de façon très marginale.
L'élimination des problèmes imprévus fait partie des
objectifs de réduction des risques.
3.2.4.3 Activités et Phases
L'objectif d'un processus unifié est de
maîtriser la complexité des projets informatiques en diminuant les
risques.
UP est un ensemble de principes génériques
adapté en fonctions des spécificités des projets. UP
répond aux préoccupations suivantes :
· QUI participe au projet ?
· QUOI, qu'est-ce qui est produit durant le projet ?
· COMMENT doit-il être réalisé ?
· QUAND est réalisé chaque livrable ?
UP gère le développement selon deux axes.
· L'axe vertical représente les principaux
enchaînements d'activités, qui regroupent les activités
selon leur nature. Cette dimension rend compte l'aspect statique du processus
qui s'exprime en termes de composants, de processus, d'activités,
d'enchaînements, d'artefacts et de travailleurs.
· L'axe horizontal représente le temps et montre
le déroulement du cycle de vie du processus ; cette dimension rend
compte de l'aspect dynamique du processus qui s'exprime en termes de cycles, de
phases, d'itérations et de jalons.
UP répète un certain nombre de fois une
série de cycle qui s'articule autour de 4 phases :
· Analyse des besoins ;
· Elaboration ;
· Construction ;
· Transition.
34
3.2.4.3 Les Activités
L'expression des besoins permet de :
? Inventorier les besoins principaux et fournir une liste de
leurs fonctions ;
? Recenser les besoins fonctionnels (du point de vue de
l'utilisateur) qui conduisent à l'élaboration des modèles
de cas d'utilisation ;
? Appréhender les besoins non fonctionnels (technique)
et livrer une liste des exigences.
Le modèle de cas d'utilisation présente le
système du point de vue de l'utilisateur et représente sous forme
de cas d'utilisation et d'acteur, les besoins du client.
a. Analyse : l'objectif de l'analyse est
d'accéder à une compréhension des besoins et des exigences
du client. Il s'agit de réaliser des spécifications permettant de
concevoir la solution. Un modèle d'analyse livre une
spécification complète des besoins issus des cas d'utilisation et
les Structures sous une forme qui facilite la compréhension
(scénarios), la préparation (définition de
l'architecture), la modification et la maintenance du futur système. Il
peut être considéré comme une première
ébauche du modèle de conception.
b. Conception : la conception permet
d'acquérir une compréhension approfondie des contraintes
liées au langage de programmation, à l'utilisation des composants
et au système d'exploitation. Elle détermine les principales
interfaces et les transcrit à l'aide d'une notation commune. Elle
constitue un point de départ à l'implémentation:
Elle décompose le travail d'implémentation en
sous-système ; Elle créée une abstraction transparente de
l'implémentation.
c. Implémentation :
L'implémentation est le résultat de la conception pour
implémenter le système sous formes de composants,
c'est-à-dire, de code source, de scripts, de binaires,
d'exécutables et d'autres éléments du même type. Les
objectifs principaux de l'implémentation sont de planifier les
intégrations des composants pour chaque itération, et de produire
les classes et les sous-systèmes sous formes de codes sources.
d. Test : Les tests permettent de
vérifier des résultats de l'implémentation en testant la
construction. Pour mener à bien ces tests, il faut les planifier pour
chaque itération, les implémenter en créant des cas de
tests, effectuer ces tests et prendre en compte le résultat de
chacun.
3.2.4.4 Les Phases
Cette phase porte essentiellement sur les besoins principaux
(du point de vue de l'utilisateur), l'architecture générale du
système, les risques majeurs, les délais et les coûts (On
met en place le projet).
35
Elle répond aux questions suivantes :
· Que va faire le système ?
· Par rapport aux utilisateurs principaux, quels services
va-t-il rendre ?
· Quelle va être l'architecture
générale (cible) de ce système ?
· Quels vont être : les délais, les
coûts, les ressources, les moyens à déployer ?
a. Elaboration : L'élaboration
reprend les éléments de la phase d'analyse des besoins et les
précise pour arriver à une spécification
détaillée de la solution à mettre en oeuvre.
L'élaboration permet de préciser la plupart des cas
d'utilisation, de concevoir l'architecture du système et surtout de
déterminer l'architecture de référence. Au terme de cette
phase, les chefs de projet doivent être en mesure de prévoir les
activités et d'estimer les ressources nécessaires à
l'achèvement du projet. Les taches à effectuer dans la phase
élaboration sont les suivantes :
· Créer une architecture de référence
;
· Identifier les risques, ceux qui sont de nature
à bouleverser le plan, le coût et le calendrier ;
· Définir les niveaux de qualité à
atteindre ;
· Formuler les cas d'utilisation pour couvrir les
besoins fonctionnels et planifier la phase de construction ;
· Elaborer une offre abordant les questions de
calendrier, de personnel et de budget.
b. Construction : La construction est le
moment où l'on construit le produit (architecture= produit complet). Le
produit contient tous les cas d'utilisation que les chefs de projet, en accord
avec les utilisateurs ont décidé de mettre au point pour cette
version.
c. Transition : Un groupe d'utilisateurs
essaye le produit et détecte les anomalies et défauts. Cette
phase suppose des activités comme la formation des utilisateurs clients,
la mise en oeuvre d'un service d'assistance et la correction des anomalies
constatées.
3.2.5 Le cycle de vie du processus unifié
Le processus unifié répète un certain
nombre de fois une série de cycles. Tout cycle se conclut par la
livraison d'une version du produit aux clients et s'articule en 4 phases :
création, élaboration, construction et transition, chacune
d'entre elles se subdivisant à son tour en itérations.
Chaque cycle se traduit par une nouvelle version du
système. Ce produit se compose d'un corps de code source réparti
sur plusieurs composants pouvant être compilés et
exécutés et s'accompagne de manuels et de produits
associés. Pour mener efficacement le cycle, les développeurs ont
besoin de construire toutes les représentations du produit logiciel :
36
Tableau 5 : Le cycle de vie du processus
unifié
|
Modèle des cas
d'utilisation
|
Expose les cas d'utilisation et leurs relations avec
les
utilisateurs
|
|
Modèle d'analyse
|
Détaille les cas d'utilisation et procède
à une première répartition du comportement du
système entre divers objets
|
|
Modèle de conception
|
Définit la structure statique du système sous
forme de sous-système, classes et interfaces ; Définit les cas
d'utilisation
réalisés sous forme de collaborations entre les
sous-
systèmes les classes et les interfaces
|
|
Modèle d'implémentation
|
Intègre les composants (code source) et la
correspondance entre les classes et les composants
|
|
Modèle de déploiement
|
Définit les noeuds physiques des ordinateurs et
l'affectation de ces composants sur ces noeuds.
|
|
Modèle de test
|
Décrit les cas de test vérifiant les cas
d'utilisation
|
|
Représentation de l'architecture
|
Description de l'architecture
|
Tous ces modèles sont liés. Ensemble, ils
représentent le système comme un tout. Les éléments
de chacun des modèles présentent des dépendances de
traçabilité ; ce qui facilite la compréhension et les
modifications ultérieures.
Figure 10 : La présentation cycle de vie du
processus unifié
37
Tableau 7 : Description et Enchaînement
d'activités
|
Phase
|
Description et Enchaînement
d'activités
|
|
Phase de creation
|
Traduit une idée en vision de produit fini et
présente une étude de rentabilité pour ce produit
- Que va faire le système pour les utilisateurs ?
- A quoi peut ressembler l'architecture d'un tel système ?
- Quels sont l'organisation et les coûts du développement de ce
produit ?
On fait apparaître les principaux cas d'utilisation.
L'architecture est provisoire, identification des
risques
majeurs et planification de la phase d'élaboration
|
|
Phase d'élaboration
|
Permet de préciser la plupart des cas d'utilisation et
de concevoir l'architecture du système. L'architecture doit être
exprimée sous forme de vue de chacun des modèles.
Émergence d'une architecture de référence.
A l'issue de cette phase, le chef de projet doit être en
mesure de prévoir les activités et d'estimer les ressources
nécessaires à l'achèvement du projet.
|
|
Phase de construction
|
Moment où l'on construit le produit. L'architecture de
référence se métamorphose en produit complet, elle est
maintenant stable. Le produit contient tous les
cas
d'utilisation que les chefs de projet, en accord avec les utilisateurs
ont décidé de mettre au point pour cette version. Celle ci doit
encore avoir des anomalies
|
|
Phase de transition
|
Le produit est en version bêta. Un groupe d'utilisateurs
essaye le produit et détecte les anomalies et défauts. Cette
phase suppose des activités comme la fabrication,
la
formation des utilisateurs clients, la mise en oeuvre d'un
service d'assistance et la correction des
anomalies
constatées. (Où le report de leur correction
à la version suivante)
|
23 MUSANGU LUKA, Analyse et conception des
applications objets avec Le Processus Unifié, Kinshasa, Editions de
l'Université Protestante au Congo, Juillet 2017, p46
38
CHAPITRE IV : ANALYSE ET CONCEPTION
Section 1 : Modélisation statique
La modélisation statique du système est une
activité itérative, fortement couplée avec la
modélisation dynamique. Pour les besoins de compréhension, nous
avons présenté ces deux activités de façon
séquentielle, mais dans la réalité, elles sont
effectuées quasiment en parallèle. Dans cette partie, il sera
question de s'occuper de la partie structurelle de système à
mettre en place. L'accent est beaucoup plus porté sur les
données.
Le but de la conceptualisation est de comprendre et structurer
les besoins du client : Il ne faut pas chercher l'exhaustivité, mais
clarifier, filtrer et organiser les besoins.
Le modèle conceptuel doit permettre une meilleure
compréhension du système. Il modèle conceptuel doit servir
d'interface entre tous les acteurs du projet.
Les besoins des clients sont des éléments de
traçabilité dans un processus intégrant UML. Le
modèle conceptuel joue un rôle central, il est capital de bien le
définir.
I.1. Capture de besoin
C'est dans cette point que les besoins des utilisateurs seront
capturés. La capture de besoins des utilisateurs se subdivise en deux
parties. On parle de besoins fonctionnels et les besoins techniques.
La capture des besoins se subdivise en deux parties, on parle
des besoins fonctionnels et des besoins techniques. Elle consiste à
identifier les fonctionnalités à développer dans
l'application et à décrire les spécifications techniques
à respecter lors de ce développement23.
Aucune activité d'informatisation n'est possible sans
la spécification de besoins des utilisateurs. L'informatisation
étant un projet complexe, il sera important dans cette session de
commencer la capture des besoins des utilisateurs et de terminer avec
l'élaboration. Cette session aura la structure ci-après :
1.1.1. Capture de besoin fonctionnels
La capture des besoins fonctionnels va permettre à
l'informaticien (maitre d'oeuvre) de maitriser le domaine métier
après la phase de spécification des besoins des utilisateurs
(maitre d'ouvrage). L'informaticien chargé de développement de
l'application doit s'atteler à identifier les différents acteurs
intervenant dans le processus
24 MUSANGU LUKA, Analyse et conception des
applications objets avec Le Processus Unifié, Kinshasa, Editions de
l'Université Protestante au Congo, Juillet 2017, p46
39
manuel et le rôle qu'ils jouent dans ce
système24.
Elle aboutit à un modèle des besoins
focalisé sur le métier des utilisateurs. Elle minimise le risque
de produire un système inadéquat avec les besoins des
utilisateurs. Elle fait intervenir les diagrammes ci-après :
· Diagramme de cas d'utilisation (DCU) ;
· Diagramme de séquences (DES) qui sera
exploité au niveau de vue dynamique système.
Les besoins fonctionnels sont ceux qui ont trait au comportement
du système c'est-à-dire que le système doit être
capable de faire tout, en tenant compte des attentes des utilisateurs.
Le logiciel que nous allons développer sera à
mesure de répondre à toutes les exigences des acteurs de notre
système.
Parmi ses exigences, notre application doit être capable
d'identifier tous les agents, les dépenses, bénéficiaire,
aussi décharges et nous permettre de connaître en temps
réel l'évolution des dépenses durant une période
donnée.
1.1.2. Les besoins fonctionnels de notre
système
Les besoins fonctionnels ou besoins métiers
représentent les actions que le système doit exécuter, il
ne devient opérationnel que s'il satisfait les besoins réels du
demandeur.
Notre logiciel doit couvrir principalement les besoins
fonctionnels suivants :
· Gestion d'Administration ;
· Gérer les inscriptions des élèves
;
· Gérer le paiement des frais scolaires ;
· Avoir une base de données pour le stockage et
enregistré tous les élèves ;
· Manipulation et mise à jour de la base de
données ;
· Application conçue devra fonctionner en mode 3 -
tiers (client, serveur de données, serveur d'application) :
· Chaque utilisateur possède un login et un mot de
passe unique pour accéder à cette application ;
· Administrateur où gérant peut ajouter,
supprimer, modifier ses données, gérer ses élèves,
les corps administratifs et les groupes tandis que l'agent le secrétaire
n'as que le droit de les consulter.
40
1.1.3. Capture de besoin non fonctionnels
Les besoins non fonctionnels sont des exigences qui ne
concernent pas spécifiquement le comportement du système
plutôt identifient les contraintes internes ou externes du
système. Les principaux besoins non fonctionnels de notre logiciel se
résument dans les points suivants :
· Le code doit être clair pour permettre des futures
évolutions ou améliorations ;
· La sécurité : l'application doit respecter
la confidentialité des données ;
· Un temps de réponse minime dans l'exécution
des tâches ;
· Un système disponible est accessible aux
utilisateurs 7 jours sur 7 et 24h sur 24 à n'importe quel moment ;
· L'ergonomie : l'application offre une interface
conviviale et facile à utiliser ;
· La Garantie de l'intégrité et la
cohérence des données à chaque mise à jour et
à chaque insertion ;
· Les interfaces de l'application doivent être
conviviales.
I.2. Diagramme de cas d'utilisation
Un cas d'utilisation est une manière spécifique
d'utiliser un système. Les acteurs sont à l'extérieur du
système ; ils modélisent tout ce qui interagit avec lui. Un cas
d'utilisation réalise un service de bout en bout, avec un
déclenchement, un déroulement et une fin, pour l'acteur qui
l'initie125. D'une manière générale le
maître d'ouvrage et les utilisateurs ne sont pas des informaticiens. Il
leur faut donc un moyen simple d'exprimer leurs besoins. C'est
précisément le rôle des diagrammes de cas d'utilisation qui
permettent de recueillir, d'analyser et d'organiser les besoins des
utilisateurs, et de recenser les grandes fonctionnalités d'un
système.
Bien souvent, le maître d'ouvrage et les utilisateurs ne
sont pas des informaticiens. Il leur faut donc un moyen simple d'exprimer leurs
besoins. C'est précisément le rôle des diagrammes de cas
d'utilisation qui permettent de recueillir, d'analyser et d'organiser les
besoins, et de recenser les grandes fonctionnalités d'un système.
Il s'agit donc de la première étape UML d'analyse d'un
système.
Un diagramme de cas d'utilisation capture le comportement d'un
système, d'un sous-système, d'une classe ou d'un composant tel
qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité
du système en unités cohérentes, les cas d'utilisation,
ayant un sens pour les acteurs. Les cas d'utilisation permettent d'exprimer le
besoin des utilisateurs d'un système, ils sont donc une vision
orientée utilisateur de ce besoin au contraire d'une vision
informatique26.
25 BENOIT CHARROUX, AOMAR OSMANI, YANN THIERRY-MIEG,
(c) 2010 Pearson Education France - UML2, 3e édition.
26 MUSANGU LUKA, Analyse et conception des
applications objets avec Le Processus Unifié, Kinshasa, Editions de
l'Université Protestante au Congo, Juillet 2017, p47
41
1.2.1. Les éléments de modélisation
des cas d'utilisation
a. Acteur
Un acteur représente l'abstraction d'un rôle
joué par des entités externes (utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le
système étudié27. Un acteur est un rôle
joué par une personne externe, un processus ou une chose qui Interagit
avec un système. Il se représente par un petit bonhomme avec son
nom (son rôle) inscrit dessous.
Un acteur est l'idéalisation d'un rôle
joué par une personne externe, un processus ou une chose qui interagit
avec un système. Il se représente par un petit bonhomme avec son
nom (son rôle) inscrit dessous. Il est également possible de
représenter un acteur sous la forme d'un classement
stéréotypé « acteur ».
Un acteur est l'idéalisation d'un rôle
joué par une personne externe, un processus ou une chose qui Interagit
avec un système. Il se représente par un petit bonhomme avec son
nom (son rôle) inscrit dessous.
Figure 11 : Représentation d'un
acteur
b. Cas d'utilisateur
Un cas d'utilisation est une unité cohérente
d'une fonctionnalité visible de l'extérieur. Il réalise un
service de bout en bout, avec un déclenchement, un déroulement et
une fin, pour l'acteur qui l'initie. Un cas d'utilisation modélise donc
un service rendu par le système, sans imposer le mode de
réalisation de ce service28.
Chaque cas d'utilisation spécifie un comportement
attendu du système considéré comme un tout, sans imposer
le mode de réalisation de ce comportement. Il permet de décrire
ce que le futur système devra faire, sans spécifier comment il le
fera. Dans le cadre de la branche fonctionnelle, le cas d'utilisation doit
mettre en valeur les interactions métier entre les acteurs et le
système. On exprimera donc des actions effectuées dans le cadre
du métier de l'utilisateur, par opposition à des manipulations de
l'application ou à des comportements techniques. Par exemple, on ne
développe ni la manipulation d'une IHM (Interface Homme Machine), ni la
gestion d'erreurs matérielles au travers d'un cas d'utilisation.
L'objectif est le suivant : l'ensemble des cas d'utilisation
doit décrire exhaustivement les exigences fonctionnelles du
système. Chaque cas d'utilisation
27 PASCAL ROQUES. FRANCK VALLEE, UML 2 en Action de
l'analyse des besoins à la conception, 4è édition
28 MUSANGU LUKA, p47
42
correspond donc à une fonction métier du
système, selon le point de vue d'un de ses acteurs.
Pour chaque acteur identifié durant l'étude
préliminaire, il convient de :
· Rechercher les différentes intentions
métier avec lesquelles il utilise le système ;
· Déterminer dans le cahier des charges les services
fonctionnels attendus du système.
Un cas d'utilisation est une unité cohérente
d'une fonctionnalité visible de l'extérieur. Il réalise un
service de bout en bout, avec un déclenchement, un déroulement et
une fin, pour l'acteur qui l'initie. Un cas d'utilisation modélise donc
un service rendu par le système, sans imposer le mode de
réalisation de ce service.
29 Nathanaël KASORO MULENDA, Notes des cours
de la Programmation Orienté Objet, G3 Info ISP/Gombe, 20192020, p23
Figure 12 : Formalisme de base de représentation
d'un cas d'utilisation
L'interaction entre un acteur et un cas d'utilisation se
représente comme une association. Il existe quatre catégories
d'acteurs 29 :
· Les acteurs principaux ;
· Les acteurs secondaires ;
· Le matériel externe ;
· Les autres systèmes.
Un cas d'utilisation se représente par une ellipse
contenant le nom du cas (un verbe à l'infinitif), et optionnellement,
au-dessus du nom, un stéréotype.
1.2.2. Relations dans les diagrammes de cas
d'utilisation
Une relation d'association est un chemin de communication
entre un acteur et un cas d'utilisation, elle est représentée par
un trait continu.
a. Relation d'inclusion d'un cas
d'utilisation A par rapport à un cas d'utilisation
B signifie qu'une instance de A contient
comportement décrit dans B
b. Relation d'extension d'un cas
d'utilisation A pour un cas d'utilisation B
signifie qu'une instance de A peut être
étendu par le comportement décrit dans B. Deux
caractéristiques sont à noter :
· Le caractère opérationnel dans le
déroulement du cas d'utilisation standard (A)
· La mention explication de l'expliciter du point
d'extension dans le cas d'utilisation standard.
43
c. Relation généralisation de
cas d'utilisation peut être définie conformément au
principe de la spécialisation/généralisation
déjà défini pour les classes
d. Relation entre acteurs : il est possible
de définir une relation d'héritage entre acteur afin
d'éviter de surcharger les diagrammes. Un acteur qui hérite de
toutes ses interactions.
1.2.3. Construction du diagramme de cas d'utilisation
A. Identification des acteurs
Un acteur est une entité externe qui agit sur le
système, le terme acteur ne désigne pas seulement les
utilisations humaines mais également les autres systèmes. Les
acteurs sont des classificateurs qui représentent des rôles au
travers d'une certaine utilisation (cas) et non pas des personnes physiques.
Un acteur représente un rôle joué par une
personne qui interagit avec le système par définition, les
acteurs sont à l'extérieur du système. Les acteurs se
recrutent parmi les utilisateurs du système. D'où, les acteurs
potentiels qui risquent d'interagir avec l'application sont :
· Elève ;
· Secrétaire ;
· Intendant ;
· Professeur ;
· Administrateur.
B. Recensement de cas d'utilisation
· Authentification : permet
d'identifier chaque utilisateur, et de lui donner l'accès aux
fonctionnalités qui conviennent le mieux ;
· Gérer les utilisateurs et les droits
d'accès : permet à l'administrateur d'ajouter,
supprimer, modifier ou consulter, un user. De plus chaque utilisateur lui est
associée un droit dans cette application ;
· Gérer le paiement de frais
;
· Gérer l'inscription.
1.2.4. Présentation du diagramme de cas
d'utilisation
Le diagramme de cas d'utilisation recensé par rapport
au besoin fonctionnel de nombrer système, nous avons recensé les
cas d'utilisation suivant :
44
a. Authentifier
Figure 13 : DCU « Authentifier »
Acteur : Administrateur et utilisateur
Description : Tous les utilisateurs de l'application peuvent
accéder au système. Cependant, chacun d'eux à un certain
nombre de privilèges c'est alors qu'il faut au début passer par
l'authentification en donnant son login et son mot de passe et les
privilèges seront attribués à l'utilisateur.
Analyse : on a choisi de commencer par traiter ce cas
d'utilisation par ce que c'est un cas qui initialise tous les autres cas
d'utilisation.
Une réalisation de ce cas d'utilisation «
Authentification » se fait comme suit : L'utilisateur saisie son login et
mot de passe sur la page ; authentification, après vérification
des données, le système sélectionne l'utilisateur en
cours.
b. Gérer les utilisateurs et les droits
d'accès
Figure 14 : DCU « Gérer les utilisateurs et
les droits d'accès »
45
Description : après
l'authentification, l'administrateur peut effecteur la saisie et
l'enregistrement de nouveaux utilisateur, la consultation des utilisateurs avec
possibilité de modification, d'attribution de droits d'accès
où de la suppression d'un utilisateur donné.
Analyse : une réalisation de ce cas
d'utilisation se fait comme suit :
L'administrateur peut effectuer la création d'un
utilisateur en lui attribuant les privilèges souhaités.
L'administrateur consulte la liste des utilisateurs,
sélectionne un utilisateur pour le modifier ou le supprimer.
c. Gérer le demande l'inscription
Figure 15 : DCU « Gérer le demande
d'inscription »
d. Gérer les inscriptions
Figure 16 : DCU Gérer les
inscriptions
46
1.2.5. Diagramme de cas d'utilisation global
Figure 17 : DCU Global
L'expression des besoins techniques implique également
le choix d'architecture. Ce choix est crucial puisqu'il intervient dans
l'évolutivité du système, le
47
I.3. Capture de besoin techniques 1.3.1. Matériel de
base
a. Aspect physique
Le développement de l'application sera
réalisé sur un ordinateur portable ayant les
caractéristiques suivantes :
Tableau 8 : Aspect physique
|
N°
|
MATERIELS
|
PERFORMANCE
|
|
1
|
ORDINATEUR (serveur)
|
DELL 500B, E5700, UUAR 3GHZ 10GZ, 500 GB, DVD RW, Desktop, LTP
17»
|
|
2
|
ORDINATEUR (client)
|
HP ProLiant micro server --idem
|
|
3
|
SWITCH
|
16 PORTS TP --LINKYS
|
|
4
|
ROUTER MODEM
|
4 PORTS LINKYS sans fil
|
|
5
|
GOULOTTE
|
5cm
|
|
6
|
CABLE
|
I WAYS: UTP CAT 4 CABLE 305m/2
|
|
7
|
CONNECTEURS
|
I WAYS R345 pug FOR UTP câble l00pcs/PACK
|
|
8
|
PRISE MURALE
|
RJ45 plug for UTP cable, 100 pcs/PACK
|
|
9
|
ONDULEUR SERVEUR
CLIENT
|
TIPPLE : UPS 100 VA AVR 6ømin, Smart, online, POWER
ALERT SOFTWARE
|
|
10
|
GROUPE ELECTROGENE
|
S KVA
|
|
11
|
EXTINCTEUR
|
|
|
12
|
STABILISATEUR
|
Classic Beltron (Automatic Voltage Regulator)
|
b. Aspect logique
Tableau 9 : Aspect logique
|
N°
|
Outils
|
Choix
|
|
1
|
Types réseau
|
LAN
|
|
2
|
Topologie physique
|
ETOILE
|
|
3
|
Topologie logique
|
ETHERNET
|
|
4
|
Architecture
|
Client-serveur
|
|
5
|
Système d'exploitation server
|
Windows 2008 serveur
|
|
6
|
Système d'exploitation client
|
Windows 10
|
|
7
|
Protocol
|
IPV 4
|
|
8
|
Antivirus
|
SMADÄV
|
|
9
|
SGBD
|
MySQL
|
|
10
|
Langage de programmation
|
PHP
|
1.3.2. Architecture
1.3.2.1. Architecture Client/serveur
48
temps de développement, le coût et les
performances.
1.3.2.2. Architecture monoposte où simple tiers
L'environnement de travail monoposte consiste à tout
centraliser au seul ordinateur qui regorge la logique applicative,
l'accès aux données et l'interface utilisateur. Un seul
ordinateur sur le quel, on retrouve les programmes et les données.
L'utilisateur interroge directement la base de données à partir
des requêtes via le système de gestion des Base de données
et ce dernier lui répond.
Architecture simple tiers La conception de l'application est
élaborée de manière à fonctionner sur un ordinateur
unique. En fait, tous mes services fournis par l'application résident
sur la même machine et sont inclus dans l'application. Toutes
fonctionnalités sont donc comprises dans une seule couche logicielle.
Application web et services web : avec
l'épanouissement de la technologie client-serveur et web, les
consommateurs ont un accès pratiquement direct aux informations
détenues par les producteurs. De nouveaux canaux de distribution
viennent alors se substituer aux intermédiaires traditionnels. Les flots
d'informations croissant, orienté vers les clients et les consommateurs,
charge la matière des relations entre acheteurs, fournisseurs,
distributeurs, partenaires, sous-traitants.
Une application web : au travers d'un ou
plusieurs services web chargés d'adapter la présentation de
l'information au canal de distribution et aux profits des utilisateurs
(customization). Ainsi, l'utilisateur final dispose de l'information dont il a
besoin quel soit son mode d'accès. Les technologies des services web
permettent d'automatiser cette adaptation, réduisant d'autant le
coût de la diffusion de l'information exigée par le
consommateur.
1.3.2.3. L'architecture à 2 niveaux
L'architecture à deux niveaux (appelée
architecture 2-tiers, tiers caractérise les systèmes
clients/serveurs pour lesquels le client demande une ressource et le serveur la
lui fournit directement, en utilisant ses propres ressources. Cela signifie que
le serveur ne fait pas appel à une autre application afin de fournir une
partie du service.
1.3.2.4. L'architecture à 3 niveaux
Dans l'architecture à 3 niveaux (appelée
architecture 3-tiers), il existe un niveau intermédiaire,
c'est-à-dire que l'on a généralement une architecture
partagée entre : 1. Un client, c'est-à-dire l'ordinateur
demandeur de ressources, équipée d'une interface utilisateur
(généralement un navigateur web) chargée de la
présentation ; Dans l'architecture à 3 niveaux (appelées
architecture 3-tiers), il existe un niveau intermédiaire,
c'est-à-dire que l'on a généralement une architecture
partagée entre :
49
> Le client : le demandeur de ressources ;
> Le serveur d'application (appelé aussi middleware)
: le serveur chargé de fournir la ressource mais faisant appel à
un autre serveur ;
> Le serveur secondaire (généralement un
serveur de base de données), fournissant un service au premier
serveur.
Cette architecture physique est assez semblable à
l'architecture client/serveur, mais en plus des « clients » et du
serveur de données évoquées plus haut, un serveur
d'application intervient comme un troisième tiers. En effet, les
machines clientes, également appelées « clients
légers » ne contiennent que l'interface de l'application de
manière qu'elles déchargées de tout traitement. En effet
le traitement est ainsi assuré par le serveur d'application, qui sert de
liaison entre l'interface d'application et els données localisées
au niveau du serveur de données.
a. Les fondations de l'architecture de services
web
L'architecture de services web repose sur un mécanisme
de transport d'une demande de service entre un client et un serveur, tous deux
connectés au réseau.
b. Présentation de l'architecture à 3
niveaux
Dans l'architecture à 3 niveaux (appelées
architecture 3-tiers), il existe un niveau intermédiaire,
c'est-à-dire que l'on a généralement une architecture
partagée entre :
> Le client : le demandeur de ressources
> Le serveur d'application (appelé aussi middleware)
: le serveur chargé de fournir la ressource mais faisant appel à
un autre serveur
> Le serveur secondaire (généralement un
serveur de base de données), fournissant un service au premier
serveur.
1.3.2.5. Le serveur d'application (appelé
également middleware)
Le serveur d'application où middleware est
chargé de fournir la ressource mais faisant appel à un autre
serveur
1.3.2.6. Le serveur de données
Fournissant au serveur d'application les données dont
il a besoin. Pour permettre à notre logiciel de bien fonctionner en
tenant compte de l'emplacement géographique de différent bureau
de l'entreprise, nous avons opté pour un réseau local avec une
architecture Client/serveur trois-tiers. Cette architecture nous permettra de
partager les ressources du serveur de la base de données en passant par
le serveur d'application et pour être utilisé dans le
différent poste utilisateurs et d'assurer le service
50
d'impression en réseau30.
Figure 18 : Serveur de données
1.3.2.7. Clients web
Le Web est donc un ensemble de serveurs connectés
à l'Internet et proposant des ressources. L'utilisateur qui
accède à ces ressources utilise en général un type
particulier de programme client, le navigateur. Les deux principales
tâches d'un navigateur consistent à :
? Dialogué avec un serveur ;
? Afficher à l'écran les documents transmis par un
serveur.
Les navigateurs offrent des fonctionnalités bien plus
étendues que les deux tâches citées ci-dessus. Firefox
dispose par exemple d'un mécanisme d'extension par plugin qui permet
d'intégrer très facilement de nouveaux modules.
1.3.3. Choix de la plateforme de développement et
SGBD 1.2.7.1. Plateforme de développement
PHP est un langage interprété (un langage de
script) exécuté du côté serveur (comme les scripts
CGI, ASP, ...) et non du côté client (un script écrit en
JavaScript ou une applet Java s'exécute sur votre ordinateur...). La
syntaxe du langage provient de celles du langage C, du Perl et de Java. Ses
principaux atouts sont :
? Une grande communauté de développeurs
partageant des centaines de milliers d'exemples de script PHP ;
? La gratuité et la disponibilité du code source
(PHP est distribué sous licence GNU GPL) ;
? La simplicité d'écriture de scripts ;
? A possibilité d'inclure le script PHP au sein d'une
page HTML (contrairement aux scripts CGI, pour lesquels il faut écrire
des lignes de code pour afficher chaque ligne en langage HTML) ;
? La simplicité d'interfaçage avec des bases de
données (de nombreux SGBD sont supportés, mais le plus
utilisé avec ce langage est MySQL, un SGBD gratuit disponible sur de
nombreuses plateformes : Unix, Linux, Windows, MacOs X, Solaris, etc....) ;
30
www.google.fr: serveur web
[Consulté le 15/07/2024]
Cette interface pratique permet d'exécuter, très
facilement et sans grandes
51
? L'intégration au sein de nombreux serveurs web (Apache,
Microsoft IIS, etc.).
La simplicité d'interfaçage avec des bases de
données (de nombreux SGBD sont supportés, mais le plus
utilisé avec ce langage est MySQL, un SGBD gratuit Dans le cadre de
notre travail nous avons choisi le PHP.
PHP est un acronyme (HyperText Pre-processor) est un langage
de scripts généralistes et Open Source, spécialement
conçu pour le développement d'applications web. Il peut
être intégré facilement au HTML. Il permet :
? La création des sites web dynamique ;
? La programmation Orientée Objet (OO) ;
? Les interactions avec les bases de données (MySQL, SQL
Server, ...) ...
Les scripts PHP sont exécutés directement sur le
serveur avant l'envoi de la page à l'internaute. Cela a pour effet de
réduire la quantité de données
téléchargées vers l'ordinateur client (celui
utilisé par l'internaute pour consulter la page).
1.2.7.2. Langage de programmation
Nous avons utilisé le couple PHP/MySQL, et sans aucun
doute eu besoin de HTML5 /CSS pour le développement du site. Le CSS est
l'acronyme de Cascading Style Sheets, est un langage de feuille de style
utilisé pour décrire la mise en forme d'un document écrit
avec un langage de balisage. Il permet aux concepteurs de contrôler
l'apparence et la disposition de leurs pages web tandis que Le HTML («
HyperText Mark-Up Language ») est un langage dit de « marquage »
(de « structuration » ou de « balisage ») dont le
rôle est de formaliser l'écriture d'un document avec des balises
de formatage. Les balises permettent d'indiquer la façon dont doit
être présenté le document et les liens qu'il établit
avec d'autres documents.
Le langage HTML permet notamment la lecture de documents sur
Internet à partir de machines différentes, grâce au
protocole HTTP, permettant d'accéder via le réseau à des
documents repérés par une adresse unique, appelée URL.
1.2.7.3. SGBD
Dans le cadre de notre application de Gestion de paiement de
facture, nous avons opté pour le SGBD MySQL utilisable dans phpMyAdmin.
PHP MyAdmin (PMA) est une application Web de gestion pour les systèmes
de gestion de base de données MySQL réalisée en PHP et
distribuée sous licence GNU GPL. Il s'agit de l'une des plus
célèbres interfaces pour gérer une base de données
MySQL sur un serveur PHP. De nombreux hébergeurs, gratuits comme
payants, le proposent ce qui évite à l'utilisateur d'avoir
à l'installer.
52
connaissances en bases de données, des requêtes
comme les créations de table de données, insertions, mises
à jour, suppressions et modifications de structure de la base de
données, ainsi que l'attribution et la révocation de droits et
l'import/export. Ce système permet de sauvegarder commodément une
base de données sous forme de fichier .SQL et d'y transférer ses
données, même sans connaître SQL.
Les principaux avantages que présente une application
en mode phpMyAdmin sont :
? Multiplateforme ;
? Implémentation du langage SQL : MySQL respecte plus
le standard SQL, performances avec d'importants pools de connexions.
? Gratuité et solutions libres ;
? Solution client léger : rien d'autre qu'un navigateur
pour faire fonctionner l'application sur le poste de l'utilisateur...
1.2.7.4. Un serveur web
Un serveur web est un serveur informatique utilisé pour
publier des sites web sur internet ou un intranet. L'expression serveur web
désigne également le logiciel utilisé sur le serveur pour
exécuter les requêtes http, le protocole de communication
employé sur le www31. Un site est constitué,
matériellement, d'un ordinateur connecté à l'Internet, et
d'un programme tournant en permanence sur cet ordinateur, le serveur.
Le programme serveur est en attente de requêtes
transmises à son attention sur le réseau par un programme client.
Quand une requête est reçue, le programme serveur l'analyse afin
de déterminer quel est le document demandé, recherche ce document
et le transmet au programme client. Un autre type important d'interaction
consiste pour le programme client à demander au programme serveur
d'exécuter un programme, en fonction de paramètres, et de lui
transmettre le résultat.
1.2.7.5. Programmation web
La programmation web peut prendre différentes formes :
de la simple page statique à la page dynamique avec connexion à
une base de données32.
La programmation web permet de dépasser les limites
étroites des pages HTML statiques, dont le contenu est fixé
à l'avance. Le principe consiste à produire les documents HTML
par un programme associé au serveur web. Ce programme reçoit en
outre des paramètres saisis par l'utilisateur qui conditionnent la page
renvoyée par le serveur au client. Le contenu des pages est donc
construit à la demande, «
31 ENCYCLOPEDIE
wikipedia.org serveur web
[Consulté le 15/07/2024]
32 ENCYCLOPEDIE
WIKIPEDIA.ORG, Programmation web
[Consulté le 15/07/2024]
53
dynamiquement ».
Le serveur web se déroule en trois phases :
? Constitution de la requête par le client
: le navigateur construit une URL contenant le nom du programme
à exécuter, accompagné, le plus souvent, de
paramètres ;
? Réception de la requête par le serveur
: le programme serveur récupère les informations
transmises par le navigateur et déclenche l'exécution du
programme en lui fournissant les paramètres reçus ;
? Transmission de la réponse : le
programme renvoie le résultat de son exécution au serveur sous la
forme d'un document HTML, le serveur se contentant alors de faire suivre au
client.
I.4. Elaboration du système
La phase d'élaboration apporte plus de détails
aux éléments proposés lors de la capture de besoins. Le
diagramme de cas d'utilisation global qui été proposé dans
la capture de besoins sera présentée sous forme de pacquage pour
chaque acteur. Chaque pacquage sera accompagné d'une description
textuelle de cas d'utilisation et son diagramme de séquence. La partie
capture de besoins techniques aussi sera affinée pour apporter beaucoup
plus de précision.
La phase de l'élaboration reprend les
éléments de la phase d'analyse des besoins et les précise
pour arriver à une spécification détaillée de la
solution à mettre en oeuvre.
L'évaluation des risques et l'étude de la
rentabilité du projet sont aussi précisées. Un planning
est réalisé pour les phases suivantes du projet en indiquant le
nombre d'itérations à réaliser pour les phases de
construction.
Répartition de DCU globale en package
A ce stade il est question d'affiner le diagramme de cas
d'utilisation global en package maître d'ouvrage. Pour faciliter la
maitrise des fonctionnalités le DCU global présenté lors
de la capture de besoin sera découpé en sous-système. Un
sous-système (appelé package) doit avoir un nom et regrouper une
famille de fonctionnalités clairement identifiable33.
En se basant sur l'exemple de projet de création d'un
site web, le DCU global sera subdivisé en package, en affectant à
chaque acteur ces cas d'utilisation.
33 MUSANGU LUKA, p75
Figure 20 : Fiche de description textuelle « Gérer
les utilisateurs »
54
1.4.1. Package « Gérer les utilisateurs
»
Figure 19 : Gérer les utilisateurs
FICHE DE DESCRIPTION TEXTUELLE
|
Cas d'utilisation : Gérer les utilisateurs et droit
d'accès Désignation de l'application : Gestion scolaire
Nom de la développeur : MBEY Victor
|
Précondition
· Authentification de l'administrateur
· Une bonne connaissance de l'utilisateur du
système
· Création d'un administrateur Post condition
· La description de doit d'utilisateur bien
détaillé
· L'administrateur à une bonne perception des
utilisateurs et des formations qui lui sont associé
· La disponibilité des informations dans la base de
données Scenario nominal :
01 : Le système affiche unmenu principal à
l'administrateur
02 : L'administrateur saisie les informations concernant les
utilisateurs et les droits d'accès.
03 : Le système vérifie les informations saisies
04 : Le système demande la confirmation de mise à
jour
05 : L'administrateur confirme la mise à jour
06 : Le système signal à l'administrateur, scenario
alternative : il s'agit de la recherché : le scenario commence au point
03 du scenario nominal.
07 : Le système affiche le résultat
08 : L'administrative demande la liste des informations
09 : Le système prépare la liste et affiche
à l'administrateur, s'il s'agit de la suppression : le scenario au point
04 de scenario nominal
55
1.4.2. Package « Gérer l'inscription
»
Figure 22 : Gérer l'inscriptions
FICHE DE DESCRIPTION TEXTUELLE
Cas d'utilisation : Gérer les
inscriptions
Désignation de l'application : Gestion
scolaire Nom de la développeur : MBEY Victor
|
Précondition
· Une bonne maitrise du système
· Serveur accessible 24/24h et 7/7
· Authentification de caissier
· Besoin d'inscription des élèves
· Le système en état de fonctionnement
Post condition
· La description de doit d'utilisateur bien
détaillé
· L'administrateur à une bonne perception des
utilisateurs et des formations qui lui sont associé
· La disponibilité des informations dans la base de
données
Scenario nominal : « DEBUT »
01 : l'internaute lance le navigateur ;
02 : l'internaute saisie l'adresse Url de site web ;
03 : le système affiche le site web ;
04 : l'internaute clique sur l'onglet formulaire d'inscription
;
05 : le système affiche le formulaire ;
06 : l'internaute remplis le formulaire d'inscription ;
7 : l'internaute joint les dossiers
8 : l'internaute envoi le formulaire
9 : le système vérifie les informations saisies.
10 : le système prend en compte l'inscription et
génère un code inscription en PDF
|
|
56
|
11 : l'internaute imprime le code inscription. «
FIN»
|
Figure 22 : Fiche de description textuelle « Gérer
les utilisateurs » 1.4.3. Package « Gérer le paiement
Figure 23 : Fiche de description textuelle « Gérer
le paiement »
FICHE DE DESCRIPTION TEXTUELLE
|
Cas d'utilisation : Gérer de paiement
Désignation de l'application : Gestion scolaire Nom
de la développeur : MBEY Victor
|
|
Pré conditions :
> Une bonne maitrise du système ;
> Serveur accessible 24/24h et 7/7 ;
> Authentification de caissier ;
> Besoin de paiement de frais ;
> Le système en état de fonctionnement.
Post conditions :
> La description bien détaillée de paiement ;
> Le caissier à une bonne perception de l'outil
informatique ;
> La disponibilité des informations dans la base de
données.
Scénario nominal :
« DEBUT »
01 : l'intendant se connecte à l'application
02 : le logiciel affiche un menu principal au caissier
03 : l'intendant s'authentifie
04 : l'intendant sélectionne l'onglet paiement
(facture)
05 : l'intendant saisi les informations liées au
paiement
06 : le système vérifie les informations
saisies.
07 : le système notifie au caissier la validation de
l'opération et la pris en compte de paiement et génère un
reçu de paiement en PDF
08 : le caissier imprime le reçu.
|
57
|
« FIN »
Scénario alternative :
01 : S'il s'agit d'une recherche : ce scénario commence au
point 04 du scénario nominal.
02 : S'il s'agit des informations erronées : ce
scénario commence au point 04 du scénario nominal.
|
Figure 24 : Fiche de description textuelle «
Paiement »
I.5. Diagramme de classe 1.5.1. Définition
Le diagramme de classe permet de représenter l'ensemble
des informations finalisées qui sont gérées par le
domaine. Ces informations sont structurées, c'est-à-dire qu'elles
ont regroupées dans des classes. Le diagramme met en évidence
d'éventuelles relations entre ces classe34.
Alors que le diagramme de cas d'utilisation montre un
système du point de vue des acteurs, le diagramme de classes en montre
la structure interne. Il permet de fournir une représentation abstraite
des objets du système qui vont interagir ensemble pour réaliser
les cas d'utilisation. Il est important de noter qu'un même objet peut
très bien intervenir dans la réalisation de plusieurs cas
d'utilisation. Les cas d'utilisation ne réalisent donc pas une partition
des classes du diagramme de classes. Un diagramme de classes n'est donc pas
adapté (sauf cas particulier) pour détailler, décomposer,
ou illustrer la réalisation d'un cas d'utilisation particulier.
Il s'agit d'une vue statique car on ne tient pas compte du
facteur temporel dans le comportement du système. Le diagramme de
classes modélise les concepts du domaine d'application ainsi que les
concepts internes créés de toutes pièces dans le cadre de
l'implémentation d'une application. Chaque langage de Programmation
Orienté Objets donne un moyen spécifique d'implémenter le
paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais
le diagramme de classes permet de modéliser les classes du
système et leurs relations indépendamment d'un langage de
programmation particulier.
1.5.2. Concept d'objet
Un objet est un concept, une abstraction ou une chose qui a un
sens dans le contexte du système à modéliser. Chaque objet
à une identité et peut être distingué des autres
sans considérer à priori les valeurs de ses
propriétés35.
34 ROQUES P. et VALLEE F., UML 2 en action de
l'analyse des besoins à la conception, Edition EYROLLES, 2005
35 MUSANGU LUKA, Analyse et conception des
applications objets avec Le Processus Unifié, Kinshasa, Editions de
l'Université Protestante au Congo, Juillet 2017
58
a. Un objet : est une instance de classe. La
classe représente l'abstraction de ses objets, au niveau de
l'implémentation, au cours de l'exécution d'une programmation,
l'identification d'un objet correspond à une adresse mémoire.
b. Une classe : 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)
Formalisme général :
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.
Figure 25 : Attribut
Nom de Classe : le nom de la classe peut
être par un « stéréotype » ou d'autres
précisions.
Attribut : un attribut est une
propriété élémentaire d'une classe pour chaque
objet d'une classe, l'attribut prend une valeur (sauf cas d'attributs multi
values). La description complète des attributs d'une classe comporte les
caractérise suivant :
· Nom d'attribut : nom unique de sa classe ;
· Multiplicité : la multiplicité indique
le nombre minimum et le nombre maximum de la valeur possible de l'attribut pour
une instance de la classe ;
· Type : type de l'attribut (Integer, string...) ;
· Valeur initiale : la valeur par défaut à
la création de l'attribut (facultative)
Opération : Une opération est
une fonction applicable aux objets d'une classe. Une opération permet de
décrire le comportement d'un objet. Une méthode est
l'implémentation d'une opération.
Caractéristiques
· Visibilité Nom d'opération
(paramètres)
· Visibilité : se reporter aux
explications données plus loin sur ce point.
· Nom d'opération : utiliser un
verbe représentant l'action à réaliser.
59
· Paramètres : liste de
paramètres (chaque paramètre peut être décrit, en
plus de son nom, par son type et sa valeur par défaut). L'absence de
paramètre est indiquée par ().
· Type résultat : type de
(s) valeur(s) retourné(s) dépendant des types disponibles dans le
langage d'implémentation. Par défaut, une opération ne
retourne pas de valeur.
1.5.3. Recensement des règles de gestion
Nous avons comme règle de gestion :
Règle 01 : Un élève reçoit les
reçus ;
Règle 02 : Un élève effectue les paiements
;
Règle 03 : Les frais sont perçus par des agents
Règle 04 : Le formulaire d'inscription appartient
à l'élève ;
Règle 05 : Les élèves est inscrit dans une
classe.
Règle 06 : L'agent reçoit le frais d'inscription
;
Règle 07 : Les reçus accompagnent le paiement ;
Règle 08 : Les paiements concernent le frais ;
1.5.4. Identification des classes
Après notre analyse nous avons recensé les classes
ci-après :
· Elève ;
· Agent ;
· Reçu ;
· Paiement ;
· Frais
· Classe ;
· Formulaire d'inscription ; 1.5.5. Recensement des
associations
Tableau 9 : Recensement des associations
|
N°
|
Association
|
Classe objet
|
Multiplicité
|
|
Source
|
Cible
|
Source
|
Cible
|
|
01
|
Programmer
|
Agent
|
Test
|
1..1
|
1..*
|
|
02
|
Concerner
|
Paiement
|
Frais
|
1..*
|
1..1
|
|
03
|
Inscrire
|
Elève
|
Classe
|
1..*
|
1..1
|
|
04
|
Récevoir
|
Frai
|
Agent
|
1..*
|
1..1
|
|
05
|
Effectuer
|
Elève
|
Paiements
|
1..1
|
1..*
|
|
06
|
Accompagner
|
Reçu
|
Paiement
|
1..*
|
1..1
|
|
07
|
Appartenir
|
Formulaire
|
Elève
|
1..*
|
1..1
|
|
08
|
Recevoir
|
Elève
|
Reçu
|
1..1
|
1..*
|
60
1.5.6. La structure de la description des attributs
Tableau 11 : La structure de la description des
attributs
|
N°
|
Classe
|
Libellé
|
Attributs
|
Type
|
Méthode
|
|
01
|
Elève
|
Numéro Nom
Post nom Prénom Sexe
Classe Option Adresse Responsable Téléphone
|
Num Nom Post_nom Prénom Sexe
Classe Option Adresse Responsable Tél
|
Varchar Varchar Varchar Varchar Var Varchar Varchar Varchar
Varchar Varchar
|
Inscrit () Modifier () Rechercher () Fermer ()
|
|
02
|
Agent
|
Matricule
Noms
Sexe
Date de naissance
Service
Grade
Fonction
Adresse
Téléphone
|
Mat Noms Sexe Datenass Service Grade Fonction Adresse
Tél
|
Varchar Varchar Char Date Varchar Varchar Varchar Varchar
Varchar
|
Enregistrer () Modifier () Rechercher () Supprimer () Fermer
()
|
|
03
|
Reçu
|
Numéro Nom Classe Montant Reste Date
|
Num Nom Classe Montant Reste Date
|
Varchar Varchar Varchar Varchar Varchar Varchar
|
Enregistrer () Modifier () Rechercher () Supprimer () Fermer
()
|
|
04
|
Frais
|
Numéro frais Montant à payer Libellé
|
Num Montant Libellé
|
Varchar
Varchar
Varchar
|
Ajouter ()
Modifier ()
Annuler ()
|
|
05
|
Paiement
|
Numéro élève Nom
Post nom
Code classe
Designation Section
|
Num Nom Post_nom Code DesSection
|
Varchar Varchar Varchar Varchar Varchar
|
Enregistrer () Modifier () Fermer ()
|
|
06
|
Classe
|
Code Classe Libellé
|
Code Libellé
|
Varchar Varchar
|
Inscrit () Rechercher ()
|
|
07
|
Formulaire d'inscription
|
Code Inscription
Nom
Post nom
Prénom
Sexe
Classe
Option
Ecole de Provenance
Lieu et date de naissance
Code classe
Désignation classe
Code section
Désignation section
Dossier
|
Code
Nom Post_nom Prénom
Sexe
Classe
Option Provenance Naissance Code classe Dés_classe
Code_section Dés_section Dossier
|
Varchar Varchar Varchar Varchar Var Varchar Varchar Varchar
Varchar Varchar Varchar Varchar Varchar Varchar
|
Enregistrer () Modifier () Rechercher () Supprimer () Fermer
()
|
61
1.5.7. Elaboration du diagramme de classe
Appartenir
Figure 26 : Elaboration du diagramme de
classe
Frais
|
1..*
|
Concerner
|
1..1
|
Num Montant Libellé
|
1..*
|
Percevoir
|
1..1
|
|
|
|
|
|
|
|
|
|
1..1
Enregistrer () Modifier () Rechercher () Supprimer () Fermer
()
1..*
Effectuer
1..*
Recevoir
1..1
1..1
Accompagner
1..*
Frais
+Num +Montant +Libellé
Ajouter ()
Modifier ()
Annuler ()
Elève
Num
Nom Postnom Prénom Sexe
Classe Option Adresse Responsable Tél
Inscrit () Modifier () Rechercher () Fermer ()
1..1
1..*
Classe
Code Libellé
Inscrit () Rechercher ()
1..1
Inscris
Paiement
Num Nom Postnom Code DesSection
|
Enregistrer () Modifier () Fermer ()
|
Formulaire Code Nom Postnom Prénom Sexe
Classe Option Provenance Naissance Code classe Dés_classe
Code_section Dés_section Dossier
Enregistrer () Modifier () Rechercher () Supprimer () Fermer
()
1..*
Agent
Mat Noms Sexe Datenass Service Grade Fonction Adresse
Tél
Enregistrer () Modifier () Rechercher () Supprimer () Fermer
()
62
I.6. Présentation du schéma relationne
La conception générique permet d'élaborer
le modèle logique du modèle statique. Pour la réalisation
du système, une base de données est nécessaire. Afin de
parvenir à sa réalisation, le passage du modèle objet du
diagramme de classe, au modèle relationnel est nécessaire. Du
modèle statique au modèle logique des transformations sont
nécessaires. Le tableau suivant illustre ces différentes
transformations.
Tableau 11 : Règle de passage
|
Modèle objet
|
Modèle relationnel
|
|
Classe
|
Table
|
|
Attributs de type simple
|
Colonnes
|
|
Attributs de type composé
|
Clé étrangère ou colonnes
|
|
Instance
|
n-uplets
|
|
Identifiant d'objet
|
Clé primaire
|
|
Association
|
Clé étrangère ou table de lien
|
|
Héritage
|
Clé primaire sur plusieurs tables
|
a. Elève
b. Agent
d. Frais
f. Paiement
63
c. Reçu
d. Classe
La relation de dépendance est utilisée dans les
diagrammes de composants pour indiquer qu'un élément de
l'implémentation d'un composant fait appel aux
64
g. Formulaire d'inscription
I.7. Diagramme composant
Le diagramme de composant permet de représenter les
composants logiciels d'un système ainsi que les liens existants entre
ces composants.
Les composants logiciels peuvent être de deux origines :
soit des composant métiers propres à une entreprise soit des
composant disponible, parmi tous les facteurs qui concourent à la
qualité d'un logiciel, nous parlons de la notion de
réutilisabilité comme étant l'aptitude d'un logiciel
à être réutilisé, en tout ou en partie, dans des
nouvelles applications. Or, la notion de classe de par sa faible
granularité et ses connexions figées (les associations avec les
autres classes matérialisent des liens structurels), ne constitue pas
une réponse adaptée à la problématique de la
réutilisation.
Chaque composant est assimilé à un
élément exécutable du système. Il est
caractérisé par :
? Un nom ;
? Une spécification externe sous forme soi d'une ou
plusieurs interfaces requises. Soit d'une ou plusieurs interfaces fournis ;
? Un part de connexion.
Formalisme général : un composant est
représenté par un classeur avec le mot clé «
composant » ou bien par un classeur comportant une icône
représentant un module.
65
services offerts par les éléments
d'implémentation d'un autre composant. Diagramme de
composant
Figure 27 : Diagramme de composant
36 MUSANGU LUKA, Analyse et conception des
applications objets avec Le Processus Unifié, Kinshasa, Editions de
l'Université Protestante au Congo, Juillet 2017
66
Section 2 : Modélisation dynamique
La modélisation dynamique s'occupe de la partie
comportementale du système où l'on pense à des aspects
liés à la manière dont les différents traitements
seront effectués. Cette partie peut faire recours aux restes de
diagramme comportementaux selon le degré de précision à
apporter au système à mettre en place. Ici le diagramme
d'activité joue un rôle
prépondérant36.
Cette modélisation s'effectue avec le diagramme ci-dessous
:
? Diagramme de séquence ;
? Diagramme d'activité ;
? Et diagramme de dépoilement.
La modélisation des aspects dynamiques répond
globalement à la question « comment est spécifié le
comportement du système, c'est-à-dire comment sont
spécifiés les algorithmes des cas d'utilisation en parcourant le
graphe de classes et des objets ? ».
Le modèle dynamique montre le comportement du
système et l'évolution des objets dans le temps. Il identifie les
différents événements venant du monde externe et montre
l'enchaînement dans le système que provoquent ces
événements. Un événement est « quelque chose
» qui se produit à un moment donné dans le temps et qui n'a
pas de durée.
2.1. Diagramme de séquence
L'objectif du diagramme de séquences est de
représenter les interactions entre objets en indiquant la chronologie
des échanges. Cette représentation peut se réaliser par
cas d'utilisation en considérant scénarios associés.
Un diagramme de séquence se représente
globalement dans un grand rectangle avec indication du nom du diagramme en haut
à gauche.
Le diagramme de séquence est une variante du diagramme de
collaboration. Par opposition aux diagrammes de collaboration, les diagrammes
de séquence possèdent intrinsèquement une dimension
temporelle mais ne représente pas explicitement les liens entre les
objets.
Ils privilégient ainsi la représentation
temporelle à la représentation spatiale et sont plus aptes
à modéliser les aspects dynamiques du système.
En revanche, ils ne rendent pas compte du contexte des objets de
manière explicite, comme les diagrammes de collaboration.
Le diagramme de séquence permet de visualiser les
messages par une lecture de haut en bas. L'axe vertical représente le
temps, l'axe horizontal les objets qui
Figure 28 : Exemple de diagramme de
séquence
67
collaborent. Une ligne verticale en pointillé est
attachée à chaque objet et représente sa durée de
vie.
Les messages sont représentés comme dans le
diagramme de collaboration (NB : un message de retour sera
représenté avec des traits en pointillés).
2.1.1. Conception du diagramme de séquence
A. Ligne de vie.
Chaque participant possède une ligne de vie
représentée par une ligne verticale en pointillée. Une
flèche reçue par un participant modélise la
réception d'un message et se traduit par l'exécution d'une
opération. La durée de vie de l'opération est
symbolisée par un rectangle appelé dans la notation UML une barre
d'activation.
B. Message synchrone et asynchrone.
Dans un diagramme de séquence, deux types de messages
peuvent être
distingués :
? Message synchrone : Ce graphique
représente une opération d'appel synchrone dans laquelle l'objet
source envoie un message et attend un message de retour de la cible avant de
poursuivre.
Authentification
Menu principale ()
Exemple :
? Message asynchrone : Ce graphique
représente un signal asynchrone ou un appel asynchrone, pour lequel
l'objet source envoie le message et passe directement à l'étape
suivante.
68
2.1.2. Présentation de diagramme de
séquence
Après l'étude des cas d'utilisation, nous avons
pu dégager les diagrammes de
séquences correspondants dont voici les importants :
A. Diagramme de séquence « Authentification
»
Utilisateur
Saisie le login et mot de passe
Demande d'assistance
Saisir opération
Accès refusé
Erreur
Système
Analyse de l'information fourni
Affichage du formulaire
Confirmation
BOO
X X X
Figure 29 : Diagramme de séquence «
Authentification »
Lorsque l'utilisateur demande l'accès à
l'application, il doit tout d'abord s'identifier par un login et mot de passe
via le serveur d'application qui prend en charge de vérifier et
consulter la base de données. S'il est accepté, donc il y aura
l'accès au système et aux applications du menu correspondant.
Sinon le serveur d'application lui affiche un message d'erreur afin de
rectifier ses données
Figure 30 : Diagramme de séquence «
Gérer les utilisateurs et leurs droits d'accès »
69
B. Diagramme de séquence « Gérer les
utilisateurs et les droits d'accès »
Administrateur
Saisie de formulaire
Enregistrement effectuer
Else
Echec
Liste des utilisateurs
Nombre de ligne affectée
Crée l'objet sécurité utilisateur
Nombre de ligne affectée
Sécuriser Utilisateur
Save User
Compte Utilisateur
Nombre de ligne affectée
Exécution du SQL
BOO
X X X X X X
70
Lorsque l'utilisateur accède à l'application, il
peut : D'une part Saisir les données concernant le nouvel utilisateur
puis demander l'enregistrement via l'application qui prend en charge la
vérification du type des données et l'insertion dans la base de
données.
Si l'insertion est réalisée avec succès
un message informe l'utilisateur que l'enregistrement est réalisé
avec succès.
Si non un message d'erreur sera affiché.
C. Diagramme de séquence « Gérer
l'identification des élèves inscrit »
Figure 31 : Diagramme de séquence «
Gérer l'identification des élèves inscrit
»
71
D. Diagramme de séquence « Gérer
inscription »
Figure 32 : Diagramme de séquence «
Gérer le consultation »
72
E. Diagramme de séquence « Gestion de
paiement frais »
Saisie informations de l'élève
Paiement effectuer
Saisie le frais
S'authentifier
Vérification de frais
Frais admis
Figure 33 : Diagramme de séquence «
Gérer le paiement de frais »
37 MUSANGU LUKA, Analyse et conception des
applications objets avec Le Processus Unifié, Kinshasa, Editions de
l'Université Protestante au Congo, Juillet 2017
73
2.2. Diagramme d'activité (DAC)
Les diagrammes d'activités permettent de mettre
l'accent sur les traitements. Ils sont donc particulièrement de flots de
contrôle et de flots de données. Ils permettent aussi de
représenter graphiquement le comportement d'une méthode ou le
déroulement d'un cas d'utilisation. Les diagrammes d'activités
sont relativement proches des diagrammes d'états
transition37.
Une action est le plus petit traitement qui puisse être
exprimé en UML. Une action a une incidence sur l'état du
système ou en extrait une information. Les actions sont des
étapes discrètes à partir desquelles se construisent les
comportements. La notion est à rapprocher de la notion d'instruction
élémentaire d'un langage de programmation (comme VB, C#,
Java...). Une action peut être par exemple :
· Une affectation de valeur à des attributs ;
· Un accès à la valeur d'une
propriété structurelle (attribut ou terminaison d'association)
;
· La création d'un nouvel objet ou lien ; - Un
calcul arithmétique ;
· L'émission d'un signal ;
· La réception d'un signal.
Nous décrivons ci-dessous les types d'actions les plus
courants prédéfinis dans la notation UML
· Action Appeler (call opération) :
Elle correspond à l'invocation d'une opération sur un
objet de manière synchrone. L'action est terminée et les
éventuelles valeurs de retour seront ignorées. Si l'appel est
synchrone, l'appelant est bloqué pendant l'exécution de
l'opération et, le cas échéant, les valeurs de retour
pouvant être réceptionnées ;
· Groupe d'activités (activités
group) : Un groupe d'activités est une activité
regroupant de noeud et des arcs, les noeuds et les arcs peuvent appartenir
à plus d'un groupe. Un diagramme d'activités est lui-même
un groupe d'activités.
· Noeud d'activité
Les concepts communs au diagramme d'Etat-transition
:
· Transition ;
· Noeud initial (état initial) ;
· Noeud final (état final) ;
· Noeud de fin flot (état de sortie) :
· Noeud de décision (choix).
NB : Le formalisme reste identique pour ces
noeuds de contrôle. Les concepts spécifiques au diagramme
d'activité sont :
74
· Noeud de bifurcation (permet à
partir d'un flot unique entrant de créer plusieurs flots concurrents en
sortie de la barre de synchronisation) ;
· Noeud de jonction (permet, à
partir de plusieurs flots concurrents en entrée de la synchronisation,
de produire un flot unique sortant ; Le noeud de jonction est le
symétrique du noeud de bifurcation),
· Noeud de fusion (permet d'avoir
plusieurs flots entrants possibles et un seul flot sortant. Le flot sortant est
donc exécuté dès qu'un des flots entrants est
activé) ;
· Pin d'entrée et de sortie ;
· Flot d'objet ;
· Partition.
Figure 34 : Représentation
graphique
Une action correspond à un traitement qui modifie
l'état du système. Cette action peut être
appréhendée soit à un niveau élémentaire
proche d'une instruction en termes de programmation soit à un niveau
plus global correspondant à une ou plusieurs opérations.
75
a. Diagramme d'activité «
Authentification »
Utilisateur
Accéder à l'interface d'authentification
Vérification des informations saisie
Page d'accueil de site
Accepter
Profil afficher
Invalide
Figure 35 : Diagramme d'activité «
Authentification »
Description : Ce diagramme d'activité de
l'authentification d'administration à partir du lancement de
l'application, premièrement, il authentifie et il fait la
vérification de données à la fin il valide.
76
b. Diagramme d'activité « Gestion des
utilisateurs et les droits d'accès »
Saisi le nom et le mot de passe
Valide
Affichage du menu principal
Sélectionner le formulaire Utilisateurs
Choisir l'opération
Mise à jour des utilisateurs Crée le compte des
utilisateurs
Invalide
Figure 36 : Diagramme d'activité «
Gérer les utilisateurs et les droits d'accès »
Confirmation de l'opération
Administrateur
77
FICHE DE DESCRIPTION TEXTUELLE
Cas d'utilisation : Gérer les
inscriptions
Désignation de l'application : Gestion
scolaire Nom de la développeur : MBEY Victor
|
Précondition
· Une bonne maitrise du système
· Serveur accessible 24/24h et 7/7
· Authentification de caissier
· Besoin d'inscription des élèves
· Le système en état de fonctionnement
Post condition
· La description de doit d'utilisateur bien
détaillé
· L'administrateur à une bonne perception des
utilisateurs et des formations qui lui sont associé
· La disponibilité des informations dans la base de
données
Scenario nominal : « DEBUT »
01 : l'internaute lance le navigateur ;
02 : l'internaute saisie l'adresse Url de site web ;
03 : le système affiche le site web ;
04 : l'internaute clique sur l'onglet formulaire d'inscription
;
05 : le système affiche le formulaire ;
06 : l'internaute remplis le formulaire d'inscription ;
7 : l'internaute joint les dossiers
8 : l'internaute envoi le formulaire
9 : le système vérifie les informations saisies.
10 : le système prend en compte l'inscription et
génère un code inscription en PDF
11 : l'internaute imprime le code inscription. «
FIN»
|
|
Figure 37 : Fiche de description textuelle «
Gérer les utilisateurs »
Affichage de la page d'accueil
Saisie le paiement de l'élève
Vérification des informations
Fgure 35 : Diagramm é
Message d'erreur
Affichage du menu général
Choix l'onglet Frai
Lancement de l'impression
Authentification
Reçu imprimer
CAISSIER
Fin
Début
Non
Oui
Prise en compte du paiement
Traitement de la requête
Exécution de l'impression
Accéder au site
SYSTÈME
Figure 38 : Diagramme d'activité « Gestion
des paiements des frais »
78
c. Diagramme d'activité « Gestion des
paiements de frais »
Affichage du formulaire d'inscription
Remplissage du formulaire
Message d'erreur
Formulaire d'inscription imprimer
Affichage de la liste d'inscription
en pdf
Cliquer sur l'oncle inscription
Affichage de la page d'accueil
Lancement de l'impression
ÉLÈVE
Fin
Début
Non
Enregistrement des informations
Vérification des informations fournies
Traitement de la requête
Exécution de l'impression
Accéder au site
SYSTÈME
Oui
Figure 39 : Diagramme d'activité «
Gérer l'inscription des élèves »
79
d. Diagramme d'activité « Gérer
l'inscription des élèves »
80
CHAPITRE V : DEVELOPPEMENT DE L'APPLICATION
V.1. Présentation d'environnement de
développement et du SGBD V.1.1. Présentation d'environnement de
développement
En programmation informatique, un environnement de
développement est un ensemble d'outils pour augmenter la
productivité des programmeurs qui développent des logiciels.
En programmation informatique, un environnement de
développement est un ensemble d'outils pour augmenter la
productivité des programmeurs qui développent des logiciels.
Dans le cadre de notre travail, nous allons utiliser Sublime
Text 3 comme Editeur de texte.
a. Sublime
Figure 40 : SublimeText
Sublime text est un éditeur de texte qui permet au
développeur (programmeur) d'écrire son programme dans un langage
de son choix.
b. Bootstrap
Est une collection d'outils utile à la création du
design de site et d'applications
web.
V.1.2. Langages utilizes
Nous avons utilisé les langages suivants :
A. HTML
HTML (HyperText Markup Language) : il a fait son apparition
dès 1991 lors du lancement du web. Son rôle est de gérer et
organiser le contenu. C'est donc en HTML que nous écrivons ce qui doit
être affiché sur la page : du texte, des liens, des images.
B. CSS.
Pour la forme nous avons utilisé le CSS (Cascading
Style Sheet, aussi appelées Feuilles de style) le rôle du CSS est
de gérer l'apparence de la page web (agencement, positionnement,
décoration, couleurs, taille du texte...) des éléments.
C. PHP
PHP (HyperText Preprocessor). Est un langage de script qui est
principalement utilisé pour être exécuté par un
serveur web. L'objectif de ce langage est de permettre aux développeurs
web d'écrire des pages dynamiques rapidement. PHP n'est pas un langage
compilé, c'est un langage interprété par le serveur. PHP
nous permet de faire
MySQL est un serveur de bases de données relationnelles
SQL développé dans un souci de performances élevées
en lecture, ce qui signifie qu'il est davantage
81
interagir notre site avec une base de données.
Pre HyperText Processor, est un langage de script
exécuté par le serveur Web qui héberge le site (comme les
scripts CGI, ASP, ...) et non par le navigateur du visiteur (comme une page
Html, un script écrit en JavaScript ou une applet Java qui
s'exécutent directement sur votre ordinateur...). La syntaxe du langage
PHP est fortement inspirée de celles du langage C et du Perl.
Figure 41 : Logo PHP
Le langage PHP est utilisé principalement en tant que
langage de script côté serveur, ce qui veut dire que c'est le
serveur (la machine qui héberge la page web en question) qui va
interpréter le code PHP et générer du code
(constitué généralement d'XHTML ou d'HTML, de CSS, et
parfois de JavaScript) qui pourra être interprété par un
navigateur.
D. JavaScript.
JavaScript est un langage de programmation de scripts
principalement employé dans les pages web interactives et à ce
titre est une partie essentielle des applications web.
V.1.3. Présentation du SGBD
La gestion d'une base de données et de ses utilisateurs
se fait grâce à un système de gestion de bases de
données appelé aussi SGBD ou en anglais DBMS (Database management
system). Un SGBD est une collection de logiciels permettant la structuration,
le stockage, la maintenance, la mise à jour et la consultation des
données d'une BDD. Pour notre travail, nous allons développer
notre application en utilisant le MySQL comme SGBD.
Figure 42 : MySQL
MySQL est un système de gestion de base de
données (SGDB). Selon le type d'application, sa licence est libre ou
propriétaire. Il fait partie des logiciels de gestion de base de
données les plus utilisés au monde, autant par le grand public
(applications web principalement) que par des professionnels, au même
titre qu'Oracle ou Microsoft SQL Server.
82
orienté vers le service de données
déjà en place que vers celui de mises à jour
fréquentes et fortement sécurisées. Il est multithread et
multi-utilisateurs.
C'est un logiciel libre développé sous double
licence en fonction de l'utilisation qui en est faite : dans un produit libre
ou dans un produit propriétaire. Dans ce dernier cas, la licence est
payante, sinon c'est LGPL qui s'applique. Ce type de licence double est
utilisé par d'autres produits.
MySQL est un système de gestion de base de
données (SGBD). Il est distribué sous une double licence GPL et
propriétaire. Il fait partie des logiciels de gestion de base de
données les plus utilisés au monde, autant par le grand public
(applications web principalement) que par des professionnels, en concurrence
avec Oracle, Informix et Microsoft SQL Server.
Son nom vient du prénom de la fille du
Co-créateur Michael Widenius, MySQL fait allusion au Structured Query
Language, le langage de requête utilisé.
MySQL AB a été acheté le 16 janvier 2008
par Sun Microsystems pour un milliard de dollars américains. En 2009,
Sun Microsystems a été acquis par Oracle Corporation, mettant
entre les mains d'une même société les deux produits
concurrents que sont Oracle Database et MySQL. Ce rachat a été
autorisé par la Commission européenne le 21 janvier 2010.
V.2. Le serveur de données
En ce qui concerne le serveur de donnée, nous avons
utilisé WampServer.
Figure 43 : WampServer
Wamp : Signified Windows Apache MySQL PHP.
L'interface phpMyAdmin est accessible via un navigateur
internet. Elle est optimisée pour Mozilla Firefox ou Internet Explorer,
mais fonctionnera probablement avec la plupart des navigateurs internet.
Vous pouvez, indifféremment, vous connecter à
l'interface phpMyAdmin de votre ordinateur (s'il est configuré comme un
serveur) ou d'un ordinateur distant (serveur de réseau local ou serveur
web). Les serveurs fournissant le service phpMyAdmin exécutent
localement le gestionnaire de base de données MySQL, un logiciel de
gestion de serveur (par exemple apache), puis phpMyAdmin. Une combinaison de
ces logiciels est fournie dans certains paquets logiciels comme EasyPHP
(Windows) et Xampp (plusieurs plateformes) afin de configurer un ordinateur
personnel
83
comme un serveur.
Pour accéder à un interface phpMyAdmin, il faut
accéder à l'adresse internet désignée dans un
navigateur internet (il faut parfois utiliser un mot de passe). Consulter
l'aide du paquet logiciel utilisé pour obtenir cette adresse.
V.3. Codification
84
85
V.4. Presentation des interfaces
86
87
V.5. Test
En informatique, un test désigne une procédure
de vérification partielle d'un système. Son objectif principal
est d'identifier un nombre maximum de comportements problématiques du
logiciel afin d'en augmenter la qualité (si les problèmes
identifiés lors des tests sont corrigés). Néanmoins, le
test peut aussi avoir pour objectif d'apporter des informations quant à
cette qualité afin de permettre la prise en décisions.
Les tests permettent de vérifier :
? La bonne implémentation de toutes les exigences
(fonctionnelles et techniques) ; ? Le fonctionnement correct des interactions
entre les objets ;
? La bonne intégration de tous les composants dans le
logiciel.
88
Maintenant pour notre travail les tests ci-après ont
été effectué pour vérifie la cohérence, la
fiabilité de donnée :
? Nous avons commencé à test le nom de
l'utilisateur et mot de passe. Il se dégage qu'un utilisateur qui n'est
pas identifié au préalable il ne peut pas accéder dans le
système. Après trois tentatives de nom et mot dépasse
erroné, le système se bloc ;
? Nos champs ont été disposé d'une
manière à ce qu'une valeur vide ne puisse pas être
enregistrée quand vous essayez d'enregistrer un formulaire sur lequel un
champ a une valeur vide le système vous renvoi un message d'erreur qui
stipule « saisir d'abord la valeur de champs qui est vide avant
d'enregistre » ;
? etc.
V.6. Diagramme de déploiement
Le diagramme de déploiement permet de
représenter l'architecture physique supportant l'exploitation du
système. Cette architecture comprend des noeuds correspondants aux
supports physiques (serveurs, routeurs, ...) ainsi que la répartition
des artefacts logiciels (bibliothèques, exécutables, ...) sur les
noeuds. C'est un véritable réseau constitué de noeuds et
de connexion entre ces noeuds qui modélise cette architecture.
Dans UML, les diagrammes de déploiement
modélisent l'architecture physique d'un système. Les diagrammes
de déploiement affichent les relations entre les composants logiciels et
matériels du système, d'une part, et la distribution physique du
traitement, d'autre part.
Les cas d'utilisation sont centrés sur les besoins des
utilisateurs. Ils aident à construire le bon système. Les cas
d'utilisation ne fournissent pas pour autant la bonne manière de faire
le système, ni la forme de l'architecture logicielle : ils disent ce
qu'un système doit faire, non comment il doit le faire.
La vue des cas d'utilisation est une description fonctionnelle
des besoins, structurée par rapport à des acteurs. Le passage
à l'approche objet s'effectue en associant une collaboration à
chaque cas d'utilisation.
Une collaboration décrit les objets du domaine, les
connexions entre ces objets et les messages échangés par les
objets. Chaque scénario, instance du cas d'utilisation
réalisé par la collaboration se représente par une
interaction entre les objets décrits dans le contexte de la
collaboration.
A. Noeud
Un noeud correspond à une ressource matérielle
de traitement sur laquelle des artefacts seront mis en oeuvre pour
l'exploitation du système. Les noeuds peuvent être
interconnectés pour former un réseau d'éléments
physique.
89
Formalisme : Un noeud ou une instance de
noeud se présente par un cube ou
parallélépipède.
Figure 44 : Représentation de noeuds
Il est possible de représenter des noeuds
spécialisés. UML propose en standard les deux types de noeuds
suivants :
y' Unité de traitement : Ce noeuds est
une unité physique disposait de capacité de traitement des
artefacts peuvent être déployés. Une unité de
traitement est un noeud spécialisé caractérisé par
le mot-clé (( devise » ;
y' Environnement d'exécution : ce
noeud représente un particulier sur lequel certains artefacts peuvent
être exécutés. Un environnement d'exécution est un
noeud spécialisé caractérisé par le mot-clé
(( exécution environnement ».
B. Artefacts
Un artefact est la spécification d'un
élément physique qui est utilisé ou produit par le
processus de développement du logiciel ou par le déploiement du
système. C'est donc un élément concret comme par exemple :
un fichier, un exécutable ou une table d'une base de données.
Station Administration
Module Matériel et logiciel
Module
pprovisionnement
Module
Administration
Module
d'entretient
Module Profil
Application
Gestion d'inscription
Station Administration
Serveur d'utilisateur
Station Utilisateur
Module Utilisateur
Module Utilisateur
Requête
Réponse
BDD
GESTION
PERCEPTION DE
FRAIS SCOLAIRE
Base de données
Figure 45 : Diagramme de déploiement
90
91
CONCLUSION
Nous voici au terme de notre présent travail qui a
porté sur « Mise en place d'un Système d'information
informatisé pour la gestion scolaires », processus
inscription des élèves, paiement de frais afin de trouver des
solutions aux difficultés présentées. Cas de Complexe
Scolaire la CONFIANCE
Nous croyons en cette analyse, que cette étude va
considérablement améliorer la gestion de scolaire car nous avons
mis en place une base de données et une application performante afin des
stockées toutes les données.
Pour l'élaboration de ce travail nous avons recourus aux
méthodes :
> La méthode Structuro-fonctionnelle
;
> La méthode Historique ; >
La méthode Analytique ; > Et le Processus
Unifié (UP)
Ainsi qu'aux techniques telles que :
> Technique d'interview ;
> Technique d'observation ; >
Technique documentaire.
Afin de relever les anomalies du système existant.
Ce site web permettra à une meilleure visibilité
sur le plan international et national et répondre favorablement aux
attentes des utilisateurs Complexe Scolaire la CONFIANCE pour avoir
facilité les inscription.
En analysant le fonctionnement du système, nous avons
vu qu'il y avait moyen d'éliminer des interventions humaines. Ce travail
est une oeuvre humaine ; il ne peut donc l'être sans quelques
imperfections ; ainsi nous sollicitons l'indulgence de tous nos lecteurs pour
les quelques erreurs qu'ils auraient constatées en nous lisant et
restons ouvert à toute suggestion qui permettrait d'améliorer ce
travail.
Ainsi, nous demandons aux autorités de Complexe
Scolaire la CONFIANCE, précisément le service qui s'occupe du la
gestion scolaire, de se servir de ce logiciel qui du reste est un outil de
travail capable de rentabiliser ce dont ils ont besoin.
92
REFERENCES BIBLIOGRAPHIQUES
1. Ouvrages
a. Antoine Zimmermann : Conception de Systèmes
d'Information, École Nationale Supérieure des Mines de
Saint-Étienne, Pôle informatique 2013/2014
b. BERNARD PASCAL : Introduction au Système de Gestion
de Base de Données et aux Base de Données : Formation «
Gestion des données scientifiques : stockage et consultation en
utilisant des bases de données » 24 au 27 /06/08
c. BOUBKER SBIHI ET REDOUANE EL YAAGOUBI : analyse et
conception d'un système, d'information avec la méthode merise
: cas d'une bibliothèque universitaire, école des sciences de
l'information, Ed Parie, 18 Sep 2005
d. GUILLAUME RIVIERE : Informatisation du Système
d'Information, éd. - ESTIA 2è année -, Dernière
révision : Janvier 2017
e. Jacques Lonchamp : Introduction aux systèmes
informatiques (Architectures, composants, mise en oeuvre), éd.
Dunod, 2011
f. KALONJI MPANGA, Méthode à la recherche
scientifique, Ed. Crs. 2000. p6
g. KUYUNSA ; BG, SHONGA KS, Initiation aux méthodes de
la recherche en science sociale. Ed. Puez 1999. P 33
h. MUNZIMBA ENS ENZU, Notes de cours de l'initiation à
la recherche scientifique, cours de 2ème graduat,
ISC/BDD, 2014-2015, (inédit)
i. MUSANGU LUKA, Analyse et conception des applications
objets avec Le Processus Unifié, Kinshasa, Editions de
l'Université Protestante au Congo, Juillet 2017
j. NGANG BILOUNGA Jean Jacques : Méthode de Conception
des Systèmes d'Information, éd Eyrolles, 2000
k. Odile PAPINI : Bases de données, éd.
POLYTECH Université d'Aix-Marseille
l. ROQUES P. et VALLEE F, UML 2 en action de l'analyse des
besoins à la conception, Edition EYROLLES, 2005.
m. ROGER TOMLIN, la mise en place de l'information dans une
entreprise, Paris, Ed, d'organisation, 1972
n. ROQUES P. et VALLEE F, UML 2 en action de l'analyse des
besoins à la conception, Edition EYROLLES, 2005.
o. Thierry Lecroq : Bases de données, éd :
Thierry Lecroq - Université de Rouen
2. Notes de cours
a. KINKELA Initiation à la Recherche Scientifique IRS
ISG-KIN 2020
b. Méthode Analyse informatique, Note de cour
Méthode Analyse Informatique, G2 Info ISG/KIN, 2017-2018
c. MUSANGU LUKA MARCEL, Notes des cours de la Conception des
Systèmes d'Information, L2, I.S.C, 2020
93
d. Nathanaël KASORO MULENDA, Notes des cours de la
Programmation Orienté Objet, G3 Info ISP/Gombe, 2019-2020
e. S. Sumathi, S. Esakkirajan,Fundamentals of Relational
Database Management Systems,Springer - 2007, (ISBN 9783540483977)
f. TSHILUMBA Louis, Note de cours d'Initiation à la
recherche scientifique, G2 Info ISP/Gombe, 2014-2015
3. Webographie
a. ENCYCLOPEDIE COMMENTCAMARCHE, Notions sur le langage PHP
b. ENCYCLOPEDIE
WIKIPEDIA.ORG, serveur web
c. ENCYCLOPEDIE
WIKIPEDIA.ORG, Programmation web
d. Microsoft Encarta 2009
4. Dictionnaire
a. Larousse (2019). Ed. Paris
94
TABLE DES MATIERES
ÉPIGRAPHE . i
DEDICACES ii
REMERCIEMENTS ..iii
LISTE DES ABREVIATIONS ET SIGLES v
LISTE DES FIGURES vi
LISTE DE TABLEAUX viii
CHAPITRE I : INTRODUCTION 1
I.1. Mise en contexte 1
I.2. Problématique 2
I.2.1. Objectif de la recherche 3
I.2.2. Question de la recherche 3
I.2.3. Hypothèse 3
I.3. Choix et intérêt du sujet
4
I.4. Délimitation du sujet 4
I.5. Méthode et technique 4
I.5.1. Méthodologie 4
I.5.2. Techniques 5
I.6. Subdivision du travail 5
CHAPITRE II : CADRE CONCEPTUEL 6
Section 1. Notions sur le système 6
1.1 Définition 6
1.2 Sortes des systèmes 6
1.2.1 Le système d'informatique 6
1.2.2 Qualité d'un système d'informatique
6
1.2.3 Typologie des systèmes d'informatiques
7
a. Selon le degré organisation 7
b. Selon le degré d'automatisation 7
c. Selon l'architecture de traitement 7
1.2.4 Le système d'information 7
1.2.5 Type des systèmes d'information
8
a. Le système de pilotage : (appelé
également système de décision), il a comme
activités 8
b. Système d'information qui a comme
activité : 8
c. Système opérant qui a pour mission :
8
1.2.6 Rôle d'un système d'information
9
a. Objectif d'un système d'information
9
b. Qualité d'un système d'information
9
Section 2. Notions sur les données 10
95
a. Définition 10
2.1 Bases de données 10
a. Définition d'une base de données (BDD)
10
2.2 Sortes des bases de données 10
I.2.2.1. Les bases de données hiérarchiques
11
I.2.2.2. Les bases de données réseaux
11
I.2.2.3. Les bases de données relationnelles
11
I.2.2.4. Les bases de données objet 11
2.3 Système de gestion de bases de données
(SGBD) 12
a. Définition 12
b. Les SGBD les plus utilisés 12
2.4 Objectif d'un système de gestion de bases de
données (SGBD) 13
CHAPITRE III. DEMARCHE DU PROJET 14
Section 1 : Cadre d'étude 14
1.1. Structure Géographique du Complexe Scolaire
LA CONFIANCE 14
1.2. Présentation de l'école 14
1.3. Brève historique du Complexe Scolaire la
CONFIANCE 14
1.4. Structure et fonctionnement du Complexe Scolaire LA
CONFIANCE 16
1.4.1. Préfecture 16
1.4.2. La Direction des Etudes 16
1.4.3. La Direction de Discipline 16
1.4.4. Le secrétariat 16
1.4.5. Intendance 17
1.4.6. Corps professoral 17
1.4.7. Les travailleurs 17
1.5. Organigramme générale du COMPLEXE
SCOLAIRE LA CONFIANCE 18
Section 2 : Méthode conceptuel projet
19
2.1. Faisabilité opérationnelle
19
2.1.1. Planning prévisionnelle 19
2.1.2. Choix de la méthode d'ordonnancement
20
2.1.3. Identification et dénombrement des
tâches 21
2.1.4. Planning d'exécution des taches et
estimation des durés 21
2.1.5. Cucul des ranges 22
2.1.6. Calcul des dates 22
a. Date au plus tôt (Dto) 22
b. Date au plus tard (Dta) 23
2.1.7. Détermination des marges 23
2.1.8. Détermination de chemin critique.
24
96
a. Présentation de graphe avec la méthode
MPM 25
b. Diagramme de GANTT 27
2.2. Faisabilité financière 27
Section 3. Notions sur la méthode processus
unifié (UP) 29
3.1 Définitions 29
3.2 UP est piloté par les cas d'utilisation
30
3.2.1 Présentation 30
3.2.2 Stratégie des cas d'utilisation :
30
3.2.3 UP est centré sur l'architecture
31
3.2.4 Liens entre cas d'utilisation et architecture
32
3.2.4.1 Marche à suivre 32
3.2.4.2 UP est itératif et incrémental
32
3.2.4.3 Activités et Phases 33
3.2.4.3 Les Activités 34
3.2.4.4 Les Phases 34
3.2.5 Le cycle de vie du processus unifié
35
CHAPITRE IV : ANALYSE ET CONCEPTION 38
Section 1 : Modélisation statique 38
I.1. Capture de besoin 38
1.1.1. Capture de besoin fonctionnels 38
1.1.2. Les besoins fonctionnels de notre système
39
1.1.3. Capture de besoin non fonctionnels 40
I.2. Diagramme de cas d'utilisation 40
1.2.1. Les éléments de modélisation
des cas d'utilisation 41
1.2.2. Relations dans les diagrammes de cas
d'utilisation 42
1.2.3. Construction du diagramme de cas d'utilisation
43
1.2.4. Présentation du diagramme de cas
d'utilisation 43
1.2.5. Diagramme de cas d'utilisation global
46
I.3. Capture de besoin techniques 47
1.3.1. Matériel de base 47
1.3.2. Architecture 47
1.3.2.1. Architecture Client/serveur 47
1.3.2.2. Architecture monoposte où simple tiers
48
1.3.2.3. L'architecture à 2 niveaux 48
1.3.2.4. L'architecture à 3 niveaux 48
1.3.2.5. Le serveur d'application (appelé
également middleware) 49
1.3.2.6. Le serveur de données 49
1.3.2.7. Clients web 50
1.3.3. Choix de la plateforme de développement et
SGBD 50
97
1.2.7.1. Plateforme de développement
50
1.2.7.2. Langage de programmation 51
1.2.7.3. SGBD 51
1.2.7.4. Un serveur web 52
1.2.7.5. Programmation web 52
I.4. Elaboration du système 53
1.4.1. Package « Gérer les utilisateurs
» 54
1.4.2. Package « Gérer l'inscription »
55
1.4.3. Package « Gérer le paiement
56
I.5. Diagramme de classe 57
1.5.1. Définition 57
1.5.2. Concept d'objet 57
1.5.3. Recensement des règles de gestion
59
1.5.4. Identification des classes 59
1.5.6. La structure de la description des
attributs 60
1.5.7. Elaboration du diagramme de classe 61
I.6. Présentation du schéma
relationne 62
I.7. Diagramme composant 64
Section 2 : Modélisation dynamique 66
2.1. Diagramme de séquence 66
2.1.1. Conception du diagramme de
séquence 67
2.1.2. Présentation de diagramme de
séquence 68
A. Diagramme de séquence « Authentification
» 68
B. Diagramme de séquence « Gérer les
utilisateurs et les droits d'accès » 69
C. Diagramme de séquence « Gérer
l'identification des élèves inscrit » 70
D. Diagramme de séquence « Gérer
inscription » 71
E. Diagramme de séquence « Gestion de
paiement frais » 72
2.2. Diagramme d'activité (DAC) 73
a. Diagramme d'activité « Authentification
» 75
b. Diagramme d'activité « Gestion des
utilisateurs et les droits d'accès » 76
c. Diagramme d'activité « Gestion des
paiements de frais » 78
d. Diagramme d'activité « Gérer
l'inscription des élèves » 79
CHAPITRE V : DEVELOPPEMENT DE L'APPLICATION
80
V.1. Présentation d'environnement de
développement et du SGBD 80
V.1.1. Présentation d'environnement de
développement 80
V.1.2. Langages utilizes 80
V.1.3. Présentation du SGBD 81
V.2. Le serveur de données 82
V.3. Codification 83
98
V.4. Presentation des interfaces 85
V.5. Test 87
V.6. Diagramme de déploiement 88
CONCLUSION 91
REFERENCES BIBLIOGRAPHIQUES 92
TABLE DES MATIERES 94
| 
