Discussion :

[Jeune_Informaticien]

Bonjour,
Je suis en train de concevoir un cms destiné aux enseignants. Et puisque je suis débutant dans l'uml, j'aime bien avoir l'avis des connaisseurs du domaine.
Pour commencer, voici mon diagramme des cas d'utilisations, surtout concernant les extends et include que je ne suis pas sur à 100% que je les utilise bien.

Mon cms permet à l'enseignant qui est l'administrateur à faire les actions de gestion du contenu via son module d'administration.
La gestion des articles ect ... est une mise à jour et ne peut être que l'une des 3 (Ajout, modif, suppression).
Et puis en front office, y a des visiteurs et des étudiants inscrits (Ces derniers ont le privilège de recevoir les newsletters et poster des comptes-rendus).

Bref, voici mon diagramme :



Merci d'avance à celui (ceux) qui aura(ont) l'amabilité et la gentillesse de me guider.

[Z3vil]

Bonjour !

Etudiant

Je pense que, peut être, un « Etudiant » hérite depuis « Visiteur », il fait presque les mêmes choses, sauf que pour « Etudiant » il a :

- « rendre un compte-rendu »
- « Consulter le profil »
- Et « Recevoir une newletter »

(Mais il y’a le problème de « S’inscrire » !)

Et je pense aussi, un « Visiteur » il ne peut pas « Consulter le profil », il faut d’abor être inscrit, et pour le consulté il faut une authentification.

Enseignant

Je pense, que pour toutes les actions d’un « Enseignant » il faut obligatoirement une authentification (c’est un CMS). Et ce n’est pas obligatoire d’ajoute « Mise à jour », « Ajouter » etc. c’est systématiquement ils sont inclut dans le mot « Gérer XXX».

[Jeune_Informaticien]

Bonsoir,
Concernant le lien d'héritage entre l'étudiant et le visiteur, j'y avais pensé, mais comme tu le mentionne y a le problème du cas d'utilisation d'inscription.
Tu penses que c'est plus raisonnable de supprimer ce cas d'utilisation et de faire un lien d'héritage (Avec peut être un commentaire indiquant qu'un visiteur peut s'inscrire) ? Ou bien je regarde la structure actuelle ?

Sinon, dans la philosophie de mon CMS, un visiteur peut bien consulter le profil (C'est le profil de l'enseignant dans je parle et non pas le sien) vu que ça sera enfin de compte la page d'accueil du site de l'enseignant (la seule page obligatoire d'ailleurs).

J'ai ajouté mise à jour car c'est le cas d'utilisation lié à la gestion des articles, unités d'enseignement et les événements du calendrier, mais pas les autres. Et le Modifier, Ajouter, supprimer, je les ai relié avec des extends car ce sont les seules possibilités d'une mise à jour.
Enfin, c'est une histoire de rendre le diagramme plus clair et détaillé.

Merci pour la réponse en tous cas.

[Z3vil]

Bonjour !

La structure actuelle, c’est mieux on voit qu’un « Visiteur » il peut devenir un « Etudient » si il s’inscrire, seulement il faut changer « Consulter le profil » par « Consulter le profil Enseignant ».

Pour ce « Mise à jour », je pense qu’il faut disparaitre, pourquoi ? Parce que

0) dans Use case, il n'y a pas le facteur de temps & on peut commencer par n’import qu’il case.
1) il y a 4 « include », alors ils sont obligatoires avant la « mise a jour », et ce n’est pas vrais !

Exemple :



(Je ne sais qu’il type de suppression vous fait logique ou physique)

---
Taquant, c’est un CMS il faut penser que tous les CMS offres des droits d’utilisation, comme avoir un « Enseignant » il gère « les articles » , « les unités » et « événements » et un « Super Enseignant » qui fait les mêmes use cases et aussi il peut paramétrer le site, géré les Enseignants, il le donnes des droits, etc.

Aussi, les cas des mots de passe perdus…

Un étudiant « recevoir une newsletter », mais qui les crée, les envois ?

Et, aussi l'ajout <<include>> « Vérification de la date » pour cases « Cree » et « Modifier » les événements.

(Bah, si vous voulez avoir beaucoup des détails, et vous de voir)

Bonne chance !