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)

II.2. 6. IDENTIFICATION DES MESSAGES

Un message représente la spécification d'une communication unidirectionnelle entre les objets, qui transporte de l'information avec l'intention de déclencher une activité chez le récepteur.

Un message est normalement associé à deux occurrences d'événements :

- un événement d'envoi,

- un événement de réception.

⁴² Xavier Blanc et Isabelle Mounier, UML2 pour les développeurs, Edition Eyrolles, Paris, 2007, p.99.

⁴³ Pascal Roques, UML2 par la pratique (Etudes de cas et exercices corrigés), 5^e édition, Ed. Eyrolles, Paris, 2006, p.341.

38

Nous allons décrire les interactions de plus haut niveau entre les acteurs et le système :

- Pour chaque acteur, identifier quels sont les messages qui déclenchent un comportement du système attendu par l'acteur dans le cadre de son activité.

- Pour le système, identifier quels sont les messages émis à l'intention d'un acteur particulier, et qui portent une information utilisée par ce destinataire.

§ Le système reçoit les messages suivants :

- Activer le système,

- Créer, modifier ou supprimer utilisateur,

- Gérer compte (modifier mot de passe),

- Ajouter paiement étudiant,

- Imprimer listes paiements,

- Créer, modifier ou supprimer secrétaire du jury,

- Affecter secrétaire du jury au jury de telle faculté,

- Consulter cotes,

- Publier résultats,

- Consulter statistiques résultats,

- Consulter résultats,

- Introduire recours,

- Valider, modifier ou supprimer résultats.

- Consulter recours,

- Affecter, mettre à jour ou supprimer secrétaire du jury...

§ Le système émet les messages suivants :

- Afficher écran Accès autorisé,

- Afficher liste utilisateurs,

- Afficher écran compte utilisateur,

- Afficher listes paiements,

- Afficher écran impression,

- Afficher listes secrétaires du jury,

- Afficher liste affectations,

- Afficher écran cotes étudiants,

- Afficher écran résultats,

- Afficher listes résultats,

- Afficher liste recours postés,

39

- Afficher liste résultats mis à jour.

- Afficher la liste des secrétaires du jury...

II.2.7. MODELISATION DU CONTEXTE

Tous les messages (système ? acteurs) identifiés précédemment peuvent être représentés de façon synthétique sur un diagramme, que l'on peut qualifier de diagramme de contexte dynamique. De notre part, nous allons illustrer le diagramme de contexte statique.

Figure 2-2: Diagramme de contexte statique du système de publication des résultats des étudiants de l'UNIKAM

II.3. CAPTURE DES BESOINS FONCTIONNELS

La capture des besoins fonctionnels est la première étape de la branche gauche du cycle en Y. Elle formalise et détaille ce qui a été ébauché au cours de l'étude préliminaire.

La technique des cas d'utilisation est la pierre angulaire de cette étape. Elle va nous permettre de préciser l'étude du contexte fonctionnel du système, en décrivant les différentes façons qu'auront les acteurs d'utiliser le futur système.⁴⁴

Nous verrons successivement à ce point comment :

? identifier les cas d'utilisation du système par ses acteurs, ? décrire les cas d'utilisation,

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

40

? organiser les cas d'utilisation,

? identifier les classes candidates du modèle d'analyse.

Figure 2-3: Situation de la capture des besoins fonctionnels dans 2TUP

II.3.1. DETERMINATION DES CAS D'UTILISATION

Un cas d'utilisation (en anglais use case) représente un ensemble de séquences d'actions réalisées par le système et produisant un résultat observable intéressant pour un acteur particulier.

Un cas d'utilisation spécifie une fonction offerte par l'application à son environnement. Un cas d'utilisation est spécifié uniquement par un intitulé. Le concept de cas d'utilisation offre une vue fonctionnelle sur l'application.⁴⁵

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.

Un cas d'utilisation comporte donc :

- un acteur principal (c'est obligatoire),

- d'éventuels acteurs secondaires.

Le tableau ci-dessous permet d'établir le résultat de ce travail, en montrant le lien entre les cas d'utilisation identifiés, les acteurs principaux et secondaires, et les messages provenant du contexte.

⁴⁵ Xavier Blanc et Isabelle Mounier, op.cit., p.99.

41

LISTE PRELIMINAIRE DES CAS D'UTILISATION

N°	Cas d'utilisation	Acteur principal, acteurs secondaires	Message(s) émis/reçu par les acteurs
1.	S'authentifier	Utilisateur	Emet :se connecter, login + mot de passe, valider Reçois : Accès autorisé ou pas		2.
Gérer utilisateurs	Webmaster	Emet : s'authentifier, ajouter, modifier ou supprimer utilisateur Reçois : liste des utilisateurs	3.
Gérer Secrétaires des jurys	Secrétaire Général Académique	Emet : s'authentifier, afficher liste des secrétaires des jurys, sélectionner le code du secrétaire, affecter ou mettre à jour ou bloquer l'accès. Reçois : liste des Secrétaires du jury	4.
Consulter statistiques résultats	Secrétaire Général Académique	Emet : s'authentifier, consulter Reçois : statiques des résultats	5.
Gérer paiements	Caissière	Emet : s'authentifier, ajouter, modifier, supprimer paiement Reçois : liste des paiements mise à jour	6.
Publier résultats	Secrétaire du jury	Emet : s'authentifier, vérifier grilles de délibération des étudiants en ordre, charger grilles, publier Reçois : résultats disponibles	7.
Gérer publications résultats	Secrétaire du jury	Emet : s'authentifier, sélectionner publication, ajouter, modifier ou supprimer publication Reçois : liste des publications mise à jour	8.
S'Inscrire	Etudiant	Emet : Se connecter, s'inscrire Reçois : liste des étudiants inscrits au système	9.
Consulter résultats	Etudiant	Emet : s'authentifier, consulter Reçois : résultats disponibles	10.
Introduire recours	Etudiant	Emet : s'authentifier, introduire/joindre fichier de preuve Reçois : liste des recours postés	11.
Consulter recours	Secrétaire du jury	Emet : s'authentifier, sélectionner promotion, afficher recours postés, consulter Reçois : liste des recours postés

Tableau 2-2: Liste des acteurs et des messages par cas d'utilisation

42

II.3.2. DESCRIPTION PRELIMINAIRE DES CAS D'UTILISATION

Chaque cas d'utilisation doit faire l'objet d'une définition a priori qui décrit l'intention de l'acteur lorsqu'il utilise le système et les séquences d'actions principales qu'il est susceptible d'effectuer. Ces définitions servent à fixer les idées lors de l'identification des cas d'utilisation et n'ont aucun caractère exhaustif.

§ S'authentifier (Utilisateur)

Intention : S'authentifier au sein d'un système est une mesure de sécurité pour celui-ci ; Actions : se connecter, login + mot de passe, valider.

§ Gérer utilisateurs (Webmaster)

Intention : la gestion des utilisateurs est d'une importance capitale, il y a gestion d'accès dans la session ne vous concernant pas tout en étant utilisateur ;

Actions : S'authentifier, ajouter modifier et supprimer utilisateur, valider.

§ Gérer Secrétaires des jurys (Secrétaire Général Académique)

Intention : gérer affectations des secrétaires des différents jurys ;

Actions : s'authentifier, afficher liste des secrétaires des jurys, sélectionner le code du secrétaire, affecter ou mettre à jour ou bloquer l'accès.

§ Consulter statistiques résultats (Secrétaire Général Académique) Intention : valider les résultats dans différents jurys ;

Actions : s'authentifier, sélectionner numéro jury, afficher statistique.

§ Gérer paiements (Caissière)

Intention : permettre à la caissière de pouvoir gérer les paiements des étudiants afin de pouvoir s'informer en temps réel de l'état d'avancement des paiements.

Actions : s'authentifier, ajouter/modifier/supprimer paiements, produire rapport paiement.

§ Publier résultats (Secrétaire du jury)

Intention : mettre en ligne les résultats des étudiants ;

Actions : s'authentifier, vérifier grilles de délibération des étudiants en ordre, charger grilles, publier.

§ Gérer publications résultats (Secrétaire du jury)

Intention : permettre au Secrétaire du jury de pouvoir mettre à jour les publications. Il peut modifier ou supprime une publication des résultats des étudiants.

Actions : s'authentifier, sélectionner publication, ajouter, modifier ou supprimer publication.

43

§ S'Inscrire (Etudiant)

Intention : permettre à l'étudiant n'ayant pas accès à la consultation des résultats de s'inscrire c.à.d. faire partir à la plate-forme, lors de la publication de pouvoir s'authentifier pour pouvoir consulter ses résultats ou introduire un recours ;

Actions : Se connecter, s'inscrire.

§ Consulter résultats (Etudiant)

Intention : après publication des résultats la consultation des résultats est utile et, ce afin de pouvoir vérifier son bilan du travail ;

Actions : s'authentifier, sélectionner faculté/promotion, consulter.

§ Introduire recours (Etudiant)

Intention : En cas d'insatisfaction de ses résultats ou aux étudiants non délibérés, introduire recours après délibération est nécessaire pour leur bienêtre ;

Actions : s'authentifier, introduire recours, saisir les réclamations dans le formulaire, joindre les fichiers de preuve, valider, payer en ligne, choisir moyen de paiement, entrer numéro carte, introduire ;

§ Consulter recours (Secrétaire du jury)

Intention : Consulter les recours postés afin de les traiter ;

Actions : s'authentifier, sélectionner numéro promotion, afficher listes des recours postés, valider.

Maintenant que nous avons identifié les cas d'utilisation et leurs acteurs, nous allons pouvoir les représenter graphiquement sur un diagramme de cas d'utilisation, dont la notation graphique de base est la suivante :

^System

^S'inscrire

^{Consulter résultats}

^:Étudiant

^{Introduire recours}

^<<include>>

^<<include>>

^{Gérer résultats <<include>>}

^<<include>>

^{S'authentifier}

^{Publier résultats}

^<<include>>

^{:Secrétaire du jury}

^<<include>>

^{Consulter Recours}

^<<include>>

^<<include>>

^<<include>>

^{Gérer paiements}

^{Gérer utilisateurs}

^{Consulter statistiques}

^:Caissière

^{Gérer Secrétaires des jurys}

^:SGAC

^Utilisateur

^:Webmaster

44

Figure 2-4: Diagramme de cas d'utilisation pour la publication des résultats des étudiants de l'UNIKAM

45

II.3.3. DESCRIPTION DETAILLEE DES CAS D'UTILISATION

La fiche de description textuelle d'un cas d'utilisation n'est pas normalisée

par UML. Nous préconisons pour notre part la structuration suivante :

CAS D'UTILISATION « S'AUTHENTIFIER »

Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : S'authentifier

· Objectif : Ce cas d'utilisation permet de déterminer si l'utilisateur est ou non autorisé à se connecter au système. Les droits des utilisateurs sont par ailleurs utilisés pour donner ou interdire l'accès à certains éléments du système qui requièrent des privilèges adéquats.

· Acteur concerné : Utilisateur.

· Domaine fonctionnel : Gestion profils

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : L'utilisateur doit disposer un compte préalablement créé par l'administrateur système.

· Post condition : Le système autorise ou non l'accès à la page demandée à l'utilisateur.

· Scénario nominal

1. L'utilisateur saisit son nom d'utilisateur, son mot de passe et son mail.

2. Le système vérifie le nom d'utilisateur son mot de passe et son mail.

3. Le système affiche l'espace approprié pour chaque utilisateur.

· Scénario alternatif

Le nom d'utilisateur, le mot de passe et le mail sont erronés, le système affiche un message d'erreur précisant que tel champs n'est pas valide, on effectue un retour vers la page d'authentification.

Description des diagrammes d'analyse du cas d'utilisation

Pour documenter les cas d'utilisation, la description textuelle est indispensable, car elle seule permet de communiquer facilement avec les utilisateurs et de s'entendre sur la terminologie métier employée. En revanche, le texte présente des désavantages puisqu'il est difficile de montrer comment les enchaînements se succèdent, ou à quel moment les acteurs

46

secondaires sont sollicités. En outre, la maintenance des évolutions s'avère souvent fastidieuse. Il est donc recommandé de compléter la description textuelle par un ou plusieurs diagrammes dynamiques UML. La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.5.).

Figure 2-5: Diagramme de Séquence du C.U. « S'authentifier »

47

CAS D'UTILISATION « GERER UTILISATEURS » Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : Gérer utilisateurs

· Objectif : ce cas d'utilisation permet au Webmaster de pouvoir ajouter, modifier ou supprimer un compte (profil utilisateur).

· Acteur concerné : Webmaster.

· Domaine fonctionnel : Gestion utilisateurs

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021

- Description des enchaînements

· Pré condition : Le Webmaster s'est authentifié correctement au système, doit être disponible pour effectuer n'importe quelle action.

· Post condition : Les informations de l'utilisateur doivent être mise à jour pour son compte.

· Scénario nominal

? CU1 : Créer un utilisateur

1. Le Webmaster choisit d'ajouter un compte utilisateur.

2. Le système affiche le formulaire à remplir.

3. Le Webmaster rempli et valide le formulaire.

4. Le système ajoute les informations dans la base de données.

5. Le système actualise la liste des utilisateurs et l'affiche. ? CU2 : Modifier un profil utilisateur

1. Le Webmaster choisit l'utilisateur à modifier.

2. Le système affiche le formulaire de modification.

3. Le Webmaster modifie les champs voulus.

4. Le système met à jour les informations dans la base de données.

5. Le système actualise la liste des utilisateurs et l'affiche. ? CU3 : Supprimer un profil utilisateur

1. Le Webmaster choisit l'utilisateur à supprimer.

2. Le système demande une confirmation.

3. Le Webmaster confirme ou annule la suppression.

4. Le système supprime l'utilisateur de la base.

48

5. Le système actualise la liste des utilisateurs et l'affiche.

· Scénario alternatif

V' L'utilisateur existe déjà ou valeurs des champs non conforme aux types de données, formulaire non rempli : un message d'erreur sera affiché par le système.

V' La modification de données avec des champs vides, champs non conformes aux types : un message d'erreur sera affiché par le système.

V' L'utilisateur inexistant dans la base de données : un message d'erreur sera affiché. Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.6).

49

Figure 2-6: Diagramme de Séquence du C.U. « Gérer utilisateurs »

50

CAS D'UTILISATION « GERER SECRETAIRES DES JURYS »

Description textuelle du Cas d'utilisation - Sommaire d'identification

· Titre : Gérer Secrétaires des jurys

· Objectif : permettre au Secrétaire du jury de pouvoir gérer les secrétaires affectés dans différents jurys ;

· Acteur principal : Secrétaire Général Académique.

· Acteur secondaire : Secrétaire du jury

· Domaine fonctionnel : Gestion des Secrétaires des jurys.

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Le Secrétaire Général Académique s'est authentifié correctement au système.

· Post condition : La liste des Secrétaires des jurys doit être mise à jour.

· Scénario nominal

- Demander page de gestion de Secrétaires des jurys ; - Le système affiche la page.

? CU1 : Affecter Secrétaire dans un jury

1. Le SGAC Demande page d'affection d'un Secrétaire dans un jury ;

2. Le système affiche la page ;

3. Le SGAC saisi les coordonnées d'affectation ;

4. Le système vérifie la conformité ;

5. Le système enregistre et met à jour si les coordonnées sont conformes. ? CU2 : Mise à jour d'une affectation

1. Le SGAC Demande page de modification ;

2. Le système affiche la page ;

3. Le SGAC sélectionne l'affectation ;

4. Le système affiche le détail ;

5. Le SGAC saisi les informations supplémentaires ;

6. Le système vérifie la conformité,

7. Le système met à jour si les informations sont conformes.

51

? CU3 : Suppression d'une affectation

1. Le SGAC Demande page de modification ;

2. Le système affiche la page ;

3. Le SGAC du jury sélectionne l'affectation ;

4. Le système affiche les détails de l'affectation ;

5. Le SGAC du jury supprime l'affectation ;

6. Le système demande la confirmation de la suppression ;

7. Le SGAC confirme la suppression ;

8. Le système supprime l'affectation du secrétaire dans un jury et actualise la liste des affectations des secrétaires.

· Scénario Alternatif

y Erreur d'une affectation

" Le système affiche un message d'erreur ;

" Le SGAC réessaye l'affectation ;

" Le système valide l'enregistrement d'une affectation et affiche la confirmation.

y Erreur de mise à jour d'une affectation

" Le système affiche un message d'erreur ;

" Le SGAC réessaye la mise à jour ;

" Le système valide la mise à jour et affiche la confirmation.

y Erreur de suppression d'une affectation

" Le système affiche l'erreur rencontrée lors de suppression ;

" Le SGAC corrige l'erreur détectée ;

" Le système valide et affiche la confirmation.

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de

séquence (figure 2.7).

52

Figure 2-7: Diagramme de Séquence du C.U. « Gérer Secrétaires des jurys »

53

CAS D'UTILISATION « CONSULTER STATISTIQUES RESULTATS » Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : Consulter statistiques résultats

· Objectif : permettre au Secrétaire Général Académique de consulter les statistiques des résultats dans différents jurys avant la publication des résultats pour prendre une certaine décision après constat.

· Acteur concerné : Secrétaire Général Académique.

· Domaine fonctionnel : Consultation statistiques résultats

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Le SGAC s'est authentifié correctement au système.

· Post condition : Le SGAC doit normalement consulter les statistiques des résultats.

· Scénario nominal

1. Le SGAC demande la page de consultation des statistiques des résultats d'un jury ;

2. Le système lui affiche la page des résultats par jury/promotion ;

3. Le SGAC décrit un critère de recherche des informations (par exemple : sélectionner un code d'un jury quelconque et le code d'une promotion qu'il doit consulter) ;

4. Le système recherche les informations ;

· Scénario alternatif

Point 1 du scénario nominal : Code Jury non trouvé ou critère non valide - Le système affiche un message d'erreur ;

- Afficher les détails de l'information ;

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.8).

54

Figure 2-8: Diagramme de Séquence du C.U. « Consulter statistiques résultats »

CAS D'UTILISATION « GERER PAIEMENTS »

Description textuelle du Cas d'utilisation - Sommaire d'identification

· Titre : Gérer paiements

· Objectif : permettre à la caissière de pouvoir gérer les paiements des étudiants afin de pouvoir s'informer en temps réel de l'état d'avancement des paiements.

· Acteur concerné : Caissière

· Domaine fonctionnel : Gestion paiements

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : La Caissière s'est authentifiée correctement au système.

· Post condition : Les paiements sont mis à jour.

· Scénario nominal

? CU1 : Ajouter paiement

1. La Caissière choisit d'ajouter un paiement.

55

2. Le système affiche le formulaire à remplir.

3. La Caissière rempli et valide le formulaire.

4. Le système ajoute les informations dans la base de données.

5. Le système actualise la liste des paiements et l'affiche. ? CU2 : Modifier paiement

1. La Caissière choisit le numéro paiement à modifier.

2. Le système affiche le formulaire de modification.

3. Le Webmaster modifie les champs voulus.

4. Le système met à jour les informations dans la base.

5. Le système actualise la liste des paiements et l'affiche. ? CU3 : Supprimer un paiement

1. La Caissière choisit le numéro paiement à supprimer.

2. Le système demande une confirmation.

3. La Caissière confirme ou annule la suppression.

4. Le système supprime l'utilisateur dans la base de données.

5. Le système actualise la liste des paiements et l'affiche.

· Scénario alternatif

V' Les valeurs des champs non conforme aux types de données, formulaire non rempli : un message d'erreur sera affiché par le système.

V' La modification de données avec des champs vides, champs non conformes aux types : un message d'erreur sera affiché par le système.

V' Le numéro paiement inexistant dans la base de données : un message d'erreur sera affiché.

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.9).

56

Figure 2-9: Diagramme de Séquence du C.U. « Gérer paiements »

57

CAS D'UTILISATION « PUBLIER RESULTATS »

Description textuelle du Cas d'utilisation - Sommaire d'identification

· Titre : Publier résultats

Objectif : permettre au Secrétaire du jury de publier les résultats des étudiants sur le Web après validation du SGAC. L'étudiant peut venir consulter ses résultats.

· Acteur concerné : Secrétaire du jury.

· Domaine fonctionnel : Gestion résultats

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Le Secrétaire du jury s'est authentifié correctement au système.

· Post condition : Les résultats sont disponibles en ligne

· Scénario nominal

1. Le Secrétaire du jury demande la page de publication des résultats ;

2. Le système lui affiche la page correspondante ;

3. Le Secrétaire du jury charge l'élément à publier ;

4. Le Secrétaire du jury saisi les informations supplémentaire détaillant l'élément ;

5. Le système vérifie la conformité de l'élément à publier ;

6. Le système enregistre s'il est conforme.

· Scénario alternatif

Point 1 du scénario nominal : grille non conforme

- Le système renvoi l'erreur ;

- Le Secrétaire du jury réessaye ;

- Le système valide et émet un message de confirmation

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de

séquence (figure 2.10).

58

Figure 2-10: Diagramme de Séquence du C.U. « Publier résultats »

CAS D'UTILISATION « GERER PUBLICATIONS RESULTATS »

Description textuelle du Cas d'utilisation - Sommaire d'identification

· Titre : Gérer publications résultats

· Objectif : permettre au Secrétaire du jury de pouvoir mettre à jour les publications. Il peut modifier ou supprime une publication des résultats des étudiants.

· Acteur concerné : Secrétaire du jury.

· Domaine fonctionnel : Gestion résultats

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Le Secrétaire du jury s'est authentifié correctement au système.

· Post condition : La liste des publications doit être mise à jour.

· Scénario nominal

? CU1 : Mise à jour d'une publication

1. Demander page de modification ;

2. Le système affiche la page

3. Le Secrétaire du jury sélectionne la publication ;

4. Le système affiche le détail ;

5. Le Secrétaire du jury saisi les informations supplémentaires ;

59

6. Le système vérifie la conformité,

7. Le système met à jour si les informations sont conformes. ? CU2 : Suppression d'une publication

1. Le Secrétaire du jury sélectionne la publication ;

2. Le système affiche les détails de la publication ;

3. Le Secrétaire du jury supprime la publication ;

4. Le système demande la confirmation de la suppression ;

5. Le Secrétaire du jury confirme la suppression ;

6. Le système supprime l'abonné et actualise la liste des publications.

· Scénario Alternatif

? Erreur de mise à jour d'une publication

" Le système affiche un message d'erreur ;

" Le Secrétaire du jury réessaye la mise à jour ;

" Le système valide la mise à jour et affiche la confirmation.

? Erreur de suppression d'une publication

" Le système affiche l'erreur rencontrée lors de suppression ;

" Le Secrétaire du jury corrige l'erreur détectée ;

" Le système valide et affiche la confirmation.

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de

séquence (figure 2.11).

60

Figure 2-11: Diagramme de Séquence du C.U. « Gérer publications résultats »

61

CAS D'UTILISATION « S'INSCRIRE »

Description textuelle du Cas d'utilisation - Sommaire d'identification

· Titre : S'Inscrire

· Objectif : permettre à l'étudiant de s'inscrire c.à.d. faire partir à la plate-forme, lors de la publication de pouvoir s'authentifier pour pouvoir consulter ses résultats ou introduire un recours ;

· Acteur concerné : Etudiant.

· Domaine fonctionnel : Consultation résultats

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Aucune condition.

· Post condition : compte créé (l'étudiant doit devenir un client lors de sa connexion).

· Scénario nominal

1. L'Etudiant demande la page d'inscription ;

2. Le système lui affiche la page demandée ;

3. L'Etudiant saisi les coordonnées d'inscription ;

4. Le système vérifie la conformité ;

5. Le système enregistre l'étudiant dans la catégorie des clients si les coordonnées sont valides.

· Scénario alternatif

Point 1 du scénario nominal : Coordonnées inscription non valide

? Le système émet un message d'erreur ;

? L'étudiant réessaye l'inscription ;

? Le système valide l'inscription et émet un message de confirmation.

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de

séquence (figure 2.12).

62

Figure 2-12: Diagramme de Séquence du C.U. « S'inscrire »

CAS D'UTILISATION « CONSULTER RESULTATS » Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : Consulter résultats

· Objectif : permettre à l'étudiant de consulter ses résultats après publication.

· Acteur concerné : Etudiant.

· Domaine fonctionnel : Consultation résultats

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : L'étudiant s'est authentifié correctement au système.

· Post condition : L'étudiant doit normalement consulter les résultats.

· Scénario nominal

1. L'Etudiant demande la page de consultation des résultats ;

2. Le système lui affiche la page des résultats publiées ;

3. L'Etudiant décrit un critère de recherche des informations ;

4. Le système recherche les informations ;

· Scénario alternatif

63

Point 1 du scénario nominal : Code étudiant non trouvé ou critère non valide

- Le système affiche un message d'erreur ; - Afficher les détails de l'information ;

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.13).

Figure 2-13: Diagramme de Séquence du C.U. « Consulter résultats »

CAS D'UTILISATION « INTRODUIRE RECOURS » Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : Introduire recours

· Objectif : permettre à l'étudiant d'introduire ses déclarations de non satisfaction après publication des résultats.

· Acteur concerné : Etudiant.

· Domaine fonctionnel : Consultation résultats

· Version : 1.0

64

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : L'étudiant a consulté les résultats après publication.

· Post condition : Le jury a pris une décision de délibération et le client en a été averti.

· Scénario nominal

1. L'Etudiant choisit d'introduire un recours.

2. Le système affiche le formulaire à remplir.

3. L'Etudiant rempli les déclarations, joint les fichiers de preuve et valide le formulaire.

4. Le système ajoute les informations dans la base de données.

5. Le système actualise la liste des recours postés et l'affiche.

· Scénario alternatif

Au point 3 du scénario nominal : informations manquantes ou incorrectes, l'Etudiant doit compléter ou modifier sa déclaration de recours (retour au point 3 du scénario nominal). Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.14).

Figure 2-14: Diagramme de Séquence du C.U. « Introduire recours »

65

CAS D'UTILISATION « CONSULTER RECOURS » Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : Consulter recours

· Objectif : permettre à l'étudiant de consulter les recours postés par les étudiants en vue de pouvoir les traiter.

· Acteur concerné : Secrétaire du jury.

· Domaine fonctionnel : Gestion résultats.

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Le Secrétaire du jury s'est authentifié correctement au système.

· Post condition : Le Secrétaire du jury doit normalement consulter les recours postés.

· Scénario nominal

1. Le Secrétaire du jury demande la page de consultation des recours ;

2. Le système lui affiche la page des recours postés ;

3. Le Secrétaire du jury consulte les recours postés, sélectionné le nom de l'étudiant en question et télécharge les preuves de la déclaration de recours ;

4. Le système télécharge les preuves de la déclaration de recours.

· Scénario alternatif

Point 1 du scénario nominal : Critère non valide

- Le système affiche un message d'erreur ;

- Téléchargement réussie.

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.15).

66

Figure 2-15: Diagramme de Séquence du C.U. « Consulter recours »

II.3.4. STRUCTURATION DES CAS D'UTILISATION DANS DES PACKAGES

Pour définir la stratégie de regroupement des cas d'utilisation pour un projet, il convient de recourir à la liste suivante de critères : par domaine d'expertise métier, par acteur, par lot de livraison. Le mécanisme générique de regroupement d'éléments en UML s'appelle le package. Nous allons y recourir dans cette activité, afin de structurer notre ensemble de cas d'utilisation.

QU'EST-CE QU'UN PACKAGE ?

Un package UML représente un espace de nommage qui peut contenir : des éléments d'un modèle, des diagrammes qui représentent les éléments du modèle, d'autres packages.⁴⁶

Les éléments contenus dans un package : doivent représenter un ensemble fortement cohérent, sont généralement de même nature et de même niveau sémantique. Le critère de regroupement retenu pour le système de publication des résultats des étudiants de UNIKAM est le premier cité, soit le domaine d'expertise métier. Il correspond également à un découpage par ensemble d'acteurs fortement reliés. Si nous reprenons le tableau préliminaire, en affectant chaque cas d'utilisation à un package, nous obtenons ce qui suit :

⁴⁶ Pascal Roques et Franck Vallée, op.cit., p.83.

67

Cas d'utilisation	Acteurs	Package
S'authentifier	Utilisateur	Services support
Gérer utilisateurs	Webmaster
S'Inscrire	Etudiant
Consulter résultats	Etudiant	Consultation des résultats
Consulter statistiques résultats	Secrétaire Général Académique
Introduire recours	Etudiant
Gérer publications résultats	Secrétaire du jury	Gestion des résultats
Gérer Secrétaires des jurys	Secrétaire Général Académique
Publier résultats	Secrétaire du jury
Consulter recours	Secrétaire du jury
Gérer paiements	Caissière	Gestion des paiements

Tableau 2-3: Liste des cas d'utilisation et de leurs acteurs par package

Le cas d'utilisation inclus S'authentifier est mis dans un package à part, en tant que fragment commun, pour bien le distinguer des vrais cas fonctionnels qui l'incluent. Les flèches de dépendance entre packages de cas d'utilisation synthétisent les éventuelles relations entre les cas, c'est-à-dire ici les inclusions. Le schéma suivant présente la structuration proposée des cas d'utilisation. Il s'agit d'un diagramme de packages, officialisé par UML 2.

Figure 2-16: Diagramme de packages des cas d'utilisation

68

En effet, chaque package de cas d'utilisation occasionne la création d'un diagramme. La notation (from Fragments) n'est pas standard UML, mais est utilisée par plusieurs outils du marché. En voici le package attirant notre attention :

Figure 2-17: Diagramme de cas d'utilisation du package « gestion résultats »

I.3.5. IDENTIFICATION DES CLASSES CANDIDATES

Les premières classes candidates identifiées dans cette phase sont des concepts connus des utilisateurs du système, ce qu'on appelle couramment (et abusivement, puisque ce sont des classes) des objets métier. Exemples pour l'étude de cas : Cours, Etudiant, Enseignant, Paiements, etc.

Nous allons dans un second temps des concepts « applicatifs », liés à l'informatisation. Exemples pour l'étude de cas : Profil utilisateur, etc.

Nous allons formaliser ensuite ces concepts métier sous forme de classes et d'associations rassemblées dans un diagramme statique pour chaque cas d'utilisation. Ces diagrammes préliminaires, que nous appelons « diagramme de classes participantes », n'ont pas d'objectif d'exhaustivité.

Pour élargir cette première identification des concepts du système, nous allons utiliser une catégorisation des classes qui a été popularisée par le RUP. Les classes d'analyse

69

qu'ils préconisent se répartissent en trois catégories. Les trois catégories de classes d'analyse sont :

- Celles qui permettent les interactions entre le site et ses utilisateurs sont qualifiées de dialogues.

- Celles qui contiennent la cinématique de l'application sont appelés contrôles.

- Celles qui représentent les concepts métier sont qualifiées des entités.