Conception et implémentation d'un site web de publication des résultats des étudiants dans une institution universitaire (cas de l'université de Kamina)

A. DIAGRAMME DES CLASSES PARTICIPANTES

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « S'AUTHENTIFIER » Pour illustrer les différents objets en interaction en rapport avec ce cas d'utilisation Les objets y figurant sont représentés de la manière suivante :

Figure 2-18: Diagramme de classe participante du C.U. « S'authentifier »

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « GERER UTILISATEURS»

« Gérer Utilisateurs » est un cas d'utilisation qui prend en compte la manipulation des objets décrits sur le diagramme de classes participantes, ci-après :

Figure 2-19: Diagramme de classe participante du C.U. « Gérer utilisateurs »

70

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « GERER SECRETAIRES DES JURYS »

Ce diagramme présente les objets qui sont en relation lors de la réalisation du cas d'utilisation « Gérer Secrétaires des Jurys ». La représentation est la suivante :

Figure 2-20: Diagramme de classe participante du C.U. « Gérer Secrétaires des Jurys »

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « CONSULTER STATISTIQUES RESULTATS »

Pour illustrer les différents objets en interaction en rapport avec ce cas d'utilisation Les objets y figurant sont représentés de la manière suivante :

Figure 2-21: Diagramme de classe participante du C.U. « Consulter statistiques résultats »

71

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U « GERER PAIMENTS » Le cas d'utilisation « Gérer paiements » a comme les objets qui y participent ceux qui suivent :

Figure 2-22: Diagramme de classe participante du C.U. « Gérer paiements »

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « PUBLIER

RESULTATS »

« Publier résultats » est un cas d'utilisation qui prend en compte la manipulation des objets décrits sur le diagramme de classes participantes, ci-après :

Figure 2-23: Diagramme de classe participante du C.U. « Publier résultats »

72

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « GERER PUBLICATIONS RESULTATS »

Ce diagramme présente les objets qui sont en relation lors de la réalisation du cas d'utilisation « Gérer publications résultats ». La représentation est la suivante :

Figure 2-24: Diagramme de classe participante du C.U. « Gérer publications résultats »

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « S'INSCRIRE » Ce diagramme présente les objets qui sont en relation lors de la réalisation du cas d'utilisation « S'Inscrire ». La représentation est la suivante :

Figure 2-25: Diagramme de classe participante du C.U. « S'inscrire »

73

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « CONSULTER

RESULTATS »

Le cas d'utilisation « Consulter résultats » a comme les objets qui y participent ceux qui suivent :

Figure 2-26: Diagramme de classe participante du C.U. « Consulter résultats »

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « INTRODUIRE

RECOURS »

Ce diagramme présente les objets qui sont en relation lors de la réalisation du cas d'utilisation « Introduire recours ». La représentation est la suivante :

Figure 2-27: Diagramme de classe participante du C.U. « Introduire recours »

74

? DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « CONSULTER

RECOURS »

« Consulter recours » est un cas d'utilisation qui prend en compte la manipulation des objets décrits sur le diagramme de classes participantes, ci-après :

Figure 2-28: Diagramme de classe participante du C.U. « Consulter recours »

II.3.6. DEFINITION DES ITERATIONS PAR CLASSEMENT DES CAS
D'UTILISATION

Dans le cadre d'un développement itératif et incrémental, il est très utile de recourir au découpage en cas d'utilisation pour définir les itérations. À cet effet, il convient en premier lieu d'identifier les cas d'utilisation les plus critiques en termes de gestion des risques. Ces cas d'utilisation devront être traités prioritairement afin de lever au plus tôt les risques majeurs. Il sera également demandé au client d'affecter une priorité fonctionnelle à chaque cas d'utilisation, afin de livrer d'abord les cas d'utilisation les plus demandés.⁴⁷

Le tableau ci-dessous nous permettra d'organiser la manière de concevoir les différentes fonctionnalités de notre site web en tenant compte de l'ordre de priorité, de risques à gérer au cours de la réalisation du système informatique par rapport à une fonctionnalité quelconque. Et cela donne lieu aux itérations représentées dans le tableau ci-après :

⁴⁷ Pascal Roques et Franck Vallée, op.cit., p.91.

75

N°	CAS D'UTILISATION	RISQUE	PRIORITE	ITERATION
1.	S'authentifier	Bas	Moyenne	8
2.	Gérer utilisateurs	Bas	Moyenne	8
3.	Gérer Secrétaires des jurys	Bas	Moyenne	6
4.	Consulter statistiques résultats	Moyen	Haute	5
5.	Gérer paiements	Bas	Basse	7
6	Publier résultats	Moyen	Haute	4
7.	Gérer publications résultats	Bas	Basse	7		8.
S'Inscrire	Haut	Haute	1	9.
Consulter résultats	Moyen	Moyenne	3	10.
Introduire recours	Moyen	Moyenne	3	11.
Consulter recours	Bas	Basse	7

Tableau 2-4: Définition des itérations par classement des cas d'utilisation

76

CONCLUSION PARTIELLE

Dans ce chapitre nous avons fait l'étude préliminaire et la capture des besoins fonctionnels :

Pour l'étude préliminaire, nous avons présenté notre projet, nous avons recueilli les besoins fonctionnels tout en faisant le choix technique et le choix technique opérationnel, nous avons identifié les acteurs de notre futur système (5 acteurs) et nous avons conclu par modéliser le contexte.

Pour la capture des besoins fonctionnels, nous avons identifié les cas d'utilisation du système par ses acteurs (11 C.U. et 4 acteurs), décrit d'une façon détaillée les cas d'utilisation en appuyant la description textuelle par les illustrations des diagrammes de séquence ; organisé les cas d'utilisation dans des packages (4 packages) et identifié les classes candidates du modèle d'analyse en utilisant le diagramme de classe participante et le diagramme des classes de conception, nous avons chuté tout en définissant les itérations et cela par classement des cas d'utilisation.

Somme toute, nous avons eu à Dialoguer avec le client sur son expression préliminaire de besoins grâce à une description fonctionnelle qu'il comprend facilement, et Réparer la modélisation orientée objet en aidant à trouver les classes principales du futur modèle statique d'analyse.

77

CHAPITRE TROISIEME : ANALYSE ET CONCEPTION DU SYSTEME INFORMATIQUE

III.1. INTRODUCTION

La conception des sites web est un sujet à la mode !

Bref, tout pour améliorer la forme, mais où est passé le fond ? Que vient faire l'internaute sur le site ? Quelles informations s'attend-il à trouver ? Comment ces informations sont-elles structurées, reliées entre elles, mises à jour ? Bref, comment garantir que les choix de réalisation de notre site web sont bien adaptés aux objectifs de l'utilisateur ?

La réponse tient en un seul mot : modéliser ! car, « Chercher une méthode, c'est chercher un système d'opérations extériorisables qui fasse mieux que le travail de l'esprit. » (Paul VALERY, Variétés.).

Ce chapitre traite du démarrage de l'analyse et de la conception objet du système à réaliser.

III.2. ANALYSE

Pour passer à l'analyse, nous allons changer radicalement l'organisation du modèle et nous fonder sur les principes de l'approche orientée objet, notamment sur celui d'encapsulation. À cet effet, nous allons passer d'une structuration fonctionnelle via les cas d'utilisation et les packages de cas d'utilisation, à une structuration objet via les classes et les catégories.

III.2.1. DECOUPAGE EN CATEGORIES

Le découpage en catégories constitue la première activité de l'étape d'analyse (il s'affine bien sûr de manière itérative au cours du projet). Il se situe sur la branche gauche du cycle en Y et succède à la capture des besoins fonctionnels. En fin d'analyse des besoins, nous obtenons un découpage fonctionnel exprimé à travers les cas d'utilisation organisés dans le modèle de spécification fonctionnelle.

Une catégorie consiste en un regroupement logique de classes à forte cohérence interne et faible couplage externe.⁴⁸ Nous la représentons par un stéréotype de package.

La démarche mise en oeuvre dans cette section se résume en disant que : pour parvenir à faire le découpage entre catégories il faut avant tout faire la structuration des packages de cas d'utilisation, établir le diagramme de classes participantes et par là : répartir les classes candidates en catégories, élaborer les diagrammes de classes préliminaires par catégorie et en fin décider des dépendances entre catégorie. En effet, de nouvelles classes (par

⁴⁸ Pascal Roques et Franck Vallée, op.cit., p.117.

78

exemple : administrateur, profil, utilisateur) vont probablement être introduites ; certaines pourront être déplacées afin de minimiser les dépendances entre catégories.

Figure 3-1: Premier découpage en catégories

Voici les raisons de ce premier découpage :

y' La catégorie Exploitation Informatique a été isolée de la catégorie Personnels car elle correspond à un service technique classique dans toute application informatique ou site web (et donc potentiellement réutilisable), mais pas à un service métier ;

y' Les catégories délibération et paiements sont séparées du fait que : pour délibérer un étudiant ce n'est ne pas nécessairement conditionnel que ce dernier soit toujours en ordre.

III.2.2. DEPENDANCES ENTRE CATEGORIES

Posséder des éléments, un package peut également importer des éléments visibles d'un autre package. UML définit ainsi deux niveaux de visibilité : public (+) : l'élément est utilisable par tout package relié par une dépendance ; private (-) : l'élément n'est utilisable que par son package parent. En analyse, nous préfixerons simplement les classes visibles par le symbole « + ». Pour les dépendances nous allons illustrer celles des associations ainsi que celles de l'importation.

Voici quelques associations concernant la classe Résultats et des classes d'autres catégories.

79

Figure 3-2: Quelques associations concernant la classe Résultats

Voici maintenant les importations concernant ces catégories :

Figure 3-3: Illustration d'importations entre catégories

Il est à noter que l'importation est une relation unidirectionnelle, qui offre un accès aux éléments du package Résultats pour les éléments du package Personnels. En somme, même si la catégorie Résultats importe la catégorie Personnels, la classe Caissier n'a toujours pas accès à la classe Résultats. La simple différence vient du fait que l'association est par défaut une relation bidirectionnelle entre classes.

80

III.2.3. DIAGRAMME DU PACKAGE D'ANALYSE

Le schéma ci-dessous schéma de la série représente ainsi l'état préliminaire des dépendances souhaitées entre les catégories au début de la phase d'analyse. C'est un diagramme de packages au sens UML 2.0.

Figure 3-4: Diagramme de packages d'analyse

III.2.4. DEVELOPPEMENT DU MODELE STATIQUE

Le développement du modèle statique constitue la deuxième activité de l'étape d'analyse. Elle se situe sur la branche gauche du cycle en Y et succède au découpage en catégories. Les diagrammes de classes établis sommairement dans les DCP (diagrammes des classes participantes), puis réorganisés lors du découpage en catégories, vont être détaillés, complétés, et optimisés.

Pour une démarche d'élaboration du modèle statique, de par le cahier des charges, les fiches de descriptions de cas d'utilisation et le diagramme de classes participantes que nous avons fait au chapitre deuxième, nous allons : affiner les classes, affiner les associations, Ajouter les attributs, ajouter les opérations (optionnel) et puis optimiser avec la généralisation le diagramme de classes. De par notre analyse, au lieu de reprendre tous les diagrammes des classes participantes nous préférons présenter ci-dessous, le diagramme de classe du modèle statique.

^gère

^1..*

¹

81

^<<entity>>

^Paiements

^{-N°_Paiement: Int}

^{-Motif_Paiement: String}

^{-Date_Paiement: Date}

^{+ajouter() +modifier() +supprimer() +rechercher() +imprimer()}

^1..*

^effectue

¹

^<<entity>>

^Etudiant

^{-Mat_Etudiant: Int}

^{-Nom_Etudiant: String}

^{-Sexe: String}

^+get()

^+set()

^appartient

^1..*

¹

^{être destiné}

^<<entity>>

^{Secrétaire du jury}

^+créer()

^+modifier()

^+supprimer()

^{1 1..*}

^Crée

^1..*

^<<entity>>

^Profil

^{-Num_Inscription: Int -Nom_Utilisateur: String -Gmail: String -Date_Creation: Date}

^+éditer()

^+modifier()

^+supprimer()

^<<entity>>

^<<entity>>

^Promotion

^{-CodePr: Int}

^{-NomPr: String}

^{-Faculte: String}

^+get()

^+set()

^1concerne1

^1..*

¹

^Caissière

^{-Mat_Caissière: Int}

^{-Nom_Caissière: String}

^-Contact

^{+créer() +modifier() +supprimer() +affecter()}

^<<entity>>

^Résultats

^{-Num_Resultat: Int}

^{-Date_Publication: Date}

^{+éditer() +charger() +publier() +consulter() +mettre à jour() +supprimer()}

^1..*

^encode

^1..*

¹

^{+créer() +modifier() +supprimer() +affecter() -Mat_SJ: Int -Nom_SJ: String -Gmail_SJ: String}

^évolue

1..*

^1..*

^{fait référence}

¹

^<<entity>>

^Jury

^{-CodeJ: Int}

^{-NomJ: String}

^{-Effectif_Total: Int}

^{-Annee_Ac: Date}

^{être affecté}

^0..*

^<<entity>>

^Recours

1..* 1

¹

¹

^{-Num_Recours: Int -Objet: String -Plaintes: String -Date_Recours: Date}

^{+éditer() +valider() +consulter() +rejetter()}

¹

^1..*

^<<entity>>

^Cours

^{-Code_Cours: Int -Nom_Cours: String -Volume_Horaire: String -Ponderation: Int}

^+get()

^+set()

Figure 3-5: Diagramme de classes de conception

Figure 3-6: Diagramme d'interaction du C.U s'authentifier

82

III.2.5. DEVELOPPEMENT DU MODELE DYNAMIQUE

Le développement du modèle dynamique constitue la troisième activité de l'étape d'analyse. Elle se situe sur la branche gauche du cycle en Y. Il s'agit d'une activité itérative, fortement couplée avec l'activité de modélisation statique, décrite au paragraphe précédent.

Partant de la démarche d'élaboration du modèle dynamique, en nous servant de diagramme de cas d'utilisation et des fiches de la description des cas d'utilisation il est nécessaire d'identifier les scénarios (liste de scénarios) et puis formaliser ces derniers à l'aide des diagrammes d'interactions.

1. Interaction du Cas d'utilisation « S'authentifier »

Le diagramme d'interactions qui illustre le contrat d'opérations « s'authentifier » est le suivant :

83

2. Interaction du Cas d'utilisation « Gérer utilisateurs »

Le diagramme d'interactions qui illustre le contrat d'opérations « Gérer utilisateurs » est le suivant :

Figure 3-7: Diagramme d'interaction du C.U gérer utilisateurs

84

3. Interaction du Cas d'utilisation « Gérer secrétaires des jurys »

Le diagramme d'interactions qui illustre le contrat d'opérations « Gérer secrétaires des jurys » est le suivant :

Figure 3-8: Diagramme d'interaction du C.U gérer secrétaires des jurys

85

4. Interaction du Cas d'utilisation « Consulter statistiques résultats »

Le diagramme d'interactions qui illustre le contrat d'opérations « Gérer secrétaires des jurys » est le suivant :

Figure 3-9: Diagramme d'interaction du C.U consulter statistiques résultats

86

5. Interaction du Cas d'utilisation « Gérer paiements »

Le diagramme d'interactions qui illustre le contrat d'opérations « Gérer paiements » est le suivant :

Figure 3-10: Diagramme d'interaction du C.U Gérer paiements

87

6. Interaction du Cas d'utilisation « Publier résultats »

Le diagramme d'interactions qui illustre le contrat d'opérations « Publier résultats » est le suivant :

Figure 3-11: Diagramme d'interaction du C.U Publier résultats

88

7. Interaction du Cas d'utilisation « Gérer publications résultats »

Le diagramme d'interactions qui illustre le contrat d'opérations « Gérer publications résultats » est le suivant :

Figure 3-12: Diagramme d'interaction du C.U Gérer publications résultats

89

8. Interaction du Cas d'utilisation « S'Inscrire »

Le diagramme d'interactions qui illustre le contrat d'opérations « S'Inscrire » est le suivant :

Figure 3-13: Diagramme d'interaction du C.U S'Inscrire

90

9. Interaction du Cas d'utilisation « Consulter résultats »

Le diagramme d'interactions qui illustre le contrat d'opérations « Consulter résultats » est le suivant :

Figure 3-14: Diagramme d'interaction du C.U Consulter résultats

91

10. Interaction du Cas d'utilisation « Introduire recours »

Le diagramme d'interactions qui illustre le contrat d'opérations « Introduire recours » est le suivant :

Figure 3-15: Diagramme d'interaction du C.U Introduire recours

92

11. Interaction du Cas d'utilisation « Consulter recours »

Le diagramme d'interactions qui illustre le contrat d'opérations « Consulter recours » est le suivant :

Figure 3-16: Diagramme d'interaction du C.U Consulter recours

93

III.3. CONCEPTION

Le glossaire IEEE 610.12-1990 définit la conception comme (1) le processus consistant à définir l'architecture, les composants, les interfaces et d'autres caractéristiques d'un système ou d'un composant et (2) le résultat même de ce processus.

Lors de la conception, il est à savoir qu'UML permet de visualiser, de spécifier, de construire et de documenter. Ces quatre aspects vont être maintenant décrits pour l'activité de conception sur la branche droite du processus 2TUP, à la conception générique (construire le modèle logique, le modèle d'exploitation, le modèle de configuration logicielle, faire le générateur de code puis le prototypage). Pour l'activité de conception sur la branche du milieu du processus 2TUP nous avons la conception préliminaire (concevoir le déploiement, concevoir le modèle d'exploitation, organiser le modèle logique, concevoir les interfaces, concevoir la structure de la présentation, organiser la configuration logicielle) et la conception détaillée (concevoir le modèle logique et développer la configuration logicielle).

A ce propos, nous allons juste concevoir l'architecture de l'application web et construire enfin la base de données relationnelle.

III.3.1. ARCHITECTURE DU LOGICIEL

« L'ergonomie des produits informatiques ? Au-delà de la fiabilité et de la performance, les utilisateurs réclament toujours plus de confort d'utilisation et d'efficacité de l'interface... à juste titre ! » Gilles Murawiec.

Le standard IEEE 1471 définit l'architecture d'un logiciel comme l'organisation fondamentale d'un système incorporée dans ses composants, leurs interrelations, leurs relations avec l'environnement et les principes qui guident toutes les tâches de conception et d'évolution du logiciel. L'architecture logicielle définit donc la structure interne du logiciel ; c'est une manière particulière de structurer et d'organiser les éléments internes d'un logiciel ou d'un composant.

Les caractéristiques d'une bonne architecture incluent les aptitudes telles que la modularité, l'extensibilité, la résistance aux pannes, la simplicité, etc.

Plusieurs auteurs ont contribué à identifier les styles architecturaux les plus importants en génie logiciel. On distingue les styles suivants :

? les structures générales telles que les modèles en couches, les modèles en pipe, les modèles à filtres et les modèles blackboard,

? les styles de systèmes distribués tels que le client/serveur, le modèle 3-tiers, le broker,

94

? les styles de systèmes interactifs tels que le modèle Modèle-Vue-Contrôleur, le modèle Présentation-Abstraction-Contrôle, les styles de systèmes adaptables tels que le micro noyau, la réflexion et

? bien d'autres utilisés pour les systèmes en batch, les interpréteurs, les systèmes de contrôle de processus, les systèmes à base de règles.

? Pour les styles des systèmes distribués, nous avons fait le choix de l'architecture client/serveur.

Dans une architecture client/serveur, les fonctionnalités du système logiciel sont organisées en services, chaque service étant délivré par un serveur différent. Les clients sont les utilisateurs de ces services ; ils contactent les serveurs sur le réseau.

Sur les réseaux actuels, les clients et serveurs exploitent essentiellement les fonctionnalités logicielles des protocoles TCP/IP pour pouvoir solliciter des services et échanger des informations.

Le schéma suivant présente le style d'architecture en 2-tiers (client/serveur) :

Figure 3-17: choix de style des architectures logiciels

? Pour les styles de systèmes interactifs, nous avons fait le choix du patron architectural modèle-vue-contrôleur (MVC, de l'anglais model-view-controller), car est un modèle en couches destiné à répondre aux besoins des applications interactives en séparant les problématiques liées aux différents composants au sein de leur architecture respective.

Ce modèle regroupe les fonctions nécessaires en trois catégories :

V' Un modèle (modèle de données),

V' Une vue (présentation, dialogue utilisateur),

V' Un contrôleur (logique de contrôle, gestion des événements, synchronisation).

95

Cette architecture peut être schématisée de la manière suivante :

Figure 3-18: Implémentation du modèle MVC

Il existe plusieurs architectures de références :

+ Applications web ;

+ Applications clientes riches ;

+ Applications web riches ;

+ Applications mobiles ;

+ Applications à base de services ;

+ ...

? Pour l'architecture de référence, nous avons fait le choix de l'application web client

léger, car c'est un pattern architectural le plus classique aujourd'hui et correspond donc aux applications Internet/intranet pour lesquelles la configuration du client n'est pas maîtrisable, à ceci près que l'on requiert côté client un navigateur web assez récent, comprenant le langage JavaScript. Le client navigue sur des pages dotées d'intelligence (programmée en JavaScript).

? Pour les composants logiciels, nous avons retenu comme composants ceux qui suivent : ? Le navigateur client : à l'occurrence de Google Chrome, d'Opera mini, Mozilla Firefox, ? Le Framework pour le développement du code source du logiciel, à l'instar de PHP, Symphony, Laravel, ASP.NET CORE, ...

? Le Framework pour le style de présentation et d'animation des pages web, comme Bootstrap, Bulma, MDB, JQuery, AdminLte, ...

? Le serveur de données à l'exemple de MySQL, SQL Server, Oracle Server, ...

? Le serveur d'application et le serveur Web(http) : Apache, Tomcat, Glashfish, IIS, ...

^{Navigateur Internet explorer}

^{Poste Secrétaire du Jury}

^{Navigateur Opera mini}

^{Navigateur Mozilla}

^{Navigateur Safari}

^{Poste Webmaster}

^<<artifact>>

^<<artifact>>

^<<artifact>>

^<<artifact>>

^<<device>>

^<<device>>

^{Poste SGAC}

^{Poste Caissière}

^<<device>>

^<<device>>

^{SERVEUR WEB}

^<<artifact>>

^{Site web de publication des résultats.php}

Figure 3-19: Diagramme de déploiement

96

? Le choix du serveur HTTP Apache est du fait qu'Apache est un serveur HTTP open-source pour les systèmes d'exploitation modernes. Le but de ce projet est de fournir un serveur sécurisé, efficace et extensible qui fournit des services HTTP respectant les standards HTTP actuels. Nous l'avons utilisé pour nous aider à configurer les Virtual hosts afin de nous permettre de faire des tests sur le déploiement en réseau local.

? Pour les composants matériels, les matériels suivants seront utilisés :

? Les postes de travail : Les Ordinateurs Personnels et/ou téléphones intelligents (Smart phones) ;

? Les différents éléments pour la connexion sans fil comme le routeur, modem, câbles réseaux, VSAT, le point d'accès, ...

? Quant au formalisme qui va nous servir à décrire graphiquement les aspects structurels liés à l'architecture d'un logiciel : nous avons choisi le diagramme de déploiement, pour visualiser, spécifier et documenter les décisions au sujet de la topologie et de la vue physique de notre système.

97

III.3.2. CONSTRUCTION DE LA BASE DE DONNEES RELATIONNELLE

Il est possible de traduire un diagramme de classes en modèle relationnel. Bien entendu, les méthodes des classes ne sont pas traduites. Aujourd'hui, lors de la conception de bases de données, il devient de plus en plus courant d'utiliser la modélisation UML plutôt que le traditionnel modèle entités - associations.

Cependant, à moins d'avoir respecté une méthodologie adaptée, la correspondance entre le modèle objet et le modèle relationnel n'est pas une tâche facile. En effet, elle ne peut que rarement être complète puisque l'expressivité d'un diagramme de classes est bien plus grande que celle d'un schéma relationnel.

Nous référant de toutes les notions sur la représentation d'un schéma relationnel, voici notre modèle physique de données :

CREATE DATABASE pubresultat; USE pubresultat;

CREATE TABLE promotion (codepr VARCHAR (10) NOT NULL PRIMARY KEY, nompr VARCHAR (25) NOT NULL, faculte VARCHAR (80) NOT NULL);

CREATE TABLE etudiant (mat_etudiant VARCHAR (10) NOT NULL PRIMARY KEY, nom_etudiant VARCHAR (30) NOT NULL, sexe VARCHAR (10) NOT NULL)

CREATE TABLE caissiere (mat_caissiere VARCHAR (10) NOT NULL PRIMARY KEY, nom_caissiere VARCHAR (30) NOT NULL,contact VARCHAR (20));

CREATE TABLE cours (code_cours VARCHAR (10) NOT NULL PRIMARY KEY, nom_cours VARCHAR (30) NOT NULL,volume_horaire INTEGER (10), ponderation Integer (3));

CREATE TABLE paiements (num_paiement INTEGER AUTO_INCREMENT PRIMARY KEY, facultes VARCHAR (30), codepr VARCHAR (10) NOT NULL, motif_paiement VARCHAR (30) NOT NULL, montant INTEGER (10), date_paiement date, mat_etudiant VARCHAR (10) NOT NULL, mat_caissiere VARCHAR (10) NOT NULL, FOREIGN KEY (mat_etudiant) REFERENCES etudiant(mat_etudiant),FOREIGN KEY (mat_caissiere) REFERENCES caissiere(mat_caissiere), FOREIGN KEY (codepr) REFERENCES promotion(codepr));

98

CREATE TABLE secretaire_jury (mat_sj VARCHAR (10) NOT NULL PRIMARY KEY, nom_sj VARCHAR (30) NOT NULL, gmail_sj VARCHAR (25));

CREATE TABLE profil (num_inscription INTEGER AUTO_INCREMENT PRIMARY KEY,mat_etudiant VARCHAR (10) NOT NULL, nom_utilisateur VARCHAR (30) NOT NULL,mot_passe VARCHAR (10) NOT NULL,gmail VARCHAR (25), date_creation DATE, FOREIGN KEY (mat_etudiant) REFERENCES etudiant (mat_etudiant));

CREATE TABLE utilisateur (user_name VARCHAR (20) NOT NULL PRIMARY KEY, pwd VARCHAR (10) NOT NULL);

CREATE TABLE jury (code_jury VARCHAR (10) NOT NULL PRIMARY KEY, nom_jury VARCHAR (10) NOT NULL, effectif_membre INTEGER (5));

CREATE TABLE affectation (num_aff INTEGER AUTO_INCREMENT PRIMARY KEY, mat_sj VARCHAR (10) NOT NULL, codepr VARCHAR (10) NOT NULL, code_jury VARCHAR (10) NOT NULL, date_aff DATE, FOREIGN KEY (mat_sj) REFERENCES secretaire_jury (mat_sj), FOREIGN KEY (codepr) REFERENCES promotion (codepr), FOREIGN KEY (code_jury) REFERENCES jury (code_jury));

CREATE TABLE recours (num_rec INTEGER AUTO_INCREMENT PRIMARY KEY, code_jury VARCHAR (10) NOT NULL, type_session VARCHAR (15) NOT NULL, mat_etudiant VARCHAR (10) NOT NULL,codepr VARCHAR (10) NOT NULL, plaintes VARCHAR (255) NOT NULL, date_rec DATE,FOREIGN KEY (codepr) REFERENCES promotion (codepr), FOREIGN KEY (code_jury) REFERENCES jury (code_jury), FOREIGN KEY (mat_etudiant) REFERENCES etudiant (mat_etudiant));

CREATE TABLE resultat (num_res INTEGER AUTO_INCREMENT PRIMARY KEY, code_jury VARCHAR (10) NOT NULL, types_session VARCHAR (15) NOT NULL, codepr VARCHAR (10) NOT NULL, mat_etudiant VARCHAR (10) NOT NULL,maxima_gen INTEGER (10) NOT NULL, pourcentage DECIMAL (10,0) NOT NULL,decision VARCHAR (5) NOT NULL, nbre_echec INTEGER (5), date_res DATE,FOREIGN KEY (codepr) REFERENCES promotion (codepr), FOREIGN KEY (code_jury) REFERENCES jury (code_jury), FOREIGN KEY (mat_etudiant) REFERENCES etudiant (mat_etudiant));

99

CONCLUSION PARTIELLE

Dans ce chapitre, nous avons vu en particulier comment utiliser la notion de package pour définir des catégories de classes d'analyse et découper le modèle UML en blocs logiques les plus indépendants possibles. Cette structuration logique a été ensuite affinée durant toute l'étape d'analyse. Pour la conception : nous avons défini les architectures nécessaires pour notre site web (client/serveur, modèle MVC, l'application web léger) et nous avons construit notre base de données relation en utilisant MySQL comme SGBD ; mais néanmoins l'analyse restera pour le chef de projet un outil essentiel qui lui permettra d'organiser son processus de développement.

100

CHAPITRE QUATRIEME : IMPLEMENTATION IV.1. INTRODUCTION

En effet, l'évolution de l'informatique a engendré de nouveaux challenges concernant la promotion de techniques et de méthodes permettant de concevoir des interfaces graphiques utiles et utilisables (Koua et Kraak, 2004).

Un service Web est un médium standardisé permettant la communication entre les applications clients et serveurs sur le World Wide Web. Il fournit une plateforme commune permettant à des multiples applications développées avec différents langages de programmation de communiquer entres elles.⁴⁹

Les diagrammes UML développés ne sont donc qu'une façon d'exprimer un problème, ils ne constituent pas une solution. Si nous implémentions les classes telles qu'elles sont identifiées dans les cas d'utilisation fonctionnels, nous passerions à côté d'un véritable travail de conception :

- il n'y aurait pas de recherche de composants existants à réutiliser ;

- aucune recherche d'optimisation ne serait réalisée ;

- les concepts seraient mélangés et on obtiendrait des classes concentrant trop de responsabilités, c'est-à-dire un code objet lourd à maintenir. Ce serait le syndrome des classes obèses.

⁴⁹ Guy PUJOLLE, Les réseaux 2ème édition, éd. Eyrolles, Paris, 2018

101