Discussion :

[nounouuuuu201186]

Bonjour,
voici mon diagramme cas d'utilisation pour un système de recrutement en ligne. J'ai besoin de vos avis pour me corriger.
Merci.

[goldray]

Bonsoir,
Le diagramme est trop chargé !
Vous devez faire en premier lieu un diagramme de cas d'utilisation global contenant les tâches principaux de l'application ,puis, faites un diagramme de cas d'utilisation détaillé pour chaque cas d'utilisation global.

Bonne chance.

[nounouuuuu201186]

@goldray
C'est vrai. C'est ma version initiale.
J'ai apporté plusieurs modifications à cette version. Dès que je terminerai ma nouvelle version, je vais la joindre pour profiter de vos remarques.

[nounouuuuu201186]

Bonsoir,
Voici mon nouveau diagramme. J'espère profiter de vos remarques.

[goldray]

Bonsoir,
Diagramme trop chargé donc il est illisible !!
Solution: vous devez faire un diagramme global contenant les tâches principaux puis vous les détaillez en utilisant les diagrammes de cas d'utilisation détaillés.

Remarque :Il s'agit d'une authentification et non pas d'identification !

Voici comment vous pouvez améliorer votre diagramme et le rendre plus lisible.(exemple relatif à l'acteur employeur inscrit).

[nounouuuuu201186]

Bonjour,
Mais, le candidat peut aussi "consulter une offre". Si vous avez relié l'employeur au cas d'utilisation "gérer offre" et que celui-ci "include" "consulter offre", comment prendre en compte au niveau du diagramme global que le candidat peut "consulter une offre"?

Remarque :Il s'agit d'une authentification et non pas d'identification !

Je veux dire par s'identifier, LOGIN. Le fait d'entrer login et mot de passe. C'est pas le même que s'authentifier?
Merci pour votre éclaircissement.

[goldray]

Bonjour,
C'est juste un exemple comment vous pouvez améliorer votre diagramme global(j'ai bien respecté les contraintes mais juste une idée d'amélioration) .L'utilisation de l'include dans ce cas a pour but de décomposer une tâche complexe "gérer offre" ,donc d’après votre explication tout le monde pour consulter une offre même l'employeur !

Une personne peut s'authentifier s'il est déjà identifié .Identifier c'est le fait d'avoir un identifiant et un mot de passe.

[nounouuuuu201186]

L'utilisation de l'include dans ce cas a pour but de décomposer une tâche complexe "gérer offre" ,donc d’après votre explication tout le monde pour consulter une offre même l'employeur !

Un employeur peut consulter l'offre qu'il a déposée et un candidat peut consulter une offre déposée par l'employeur. C'est logique. NON?
Vraiment, je trouve un problème à décomposer mon diagramme. Si je vais introduire un cas complexe comme celui de "gérer une offre". Ce cas contient entre autres le cas "consulter une offre" qui est partagé par les deux acteurs "employeur" et "candidat". Mais, "gérer une offre" contient en plus des cas qui ne sont pas partagés entre les deux acteurs. Dans, ce cas je ne peux pas relier, dans le diagramme global, "candidat" à "gérer une offre". Est-ce qu'il serait correct, de relier "candidat" à un cas d'utilisation "consulter une offre" dans le diagramme global alors que ce même cas est contenu dans le cas complexe "gérer une offre". Cela ne serait-il pas un genre de redondance?
C'est de même pour un autre cas complexe qu'on peut introduire "gestion CV" qui peut contenir "voir CV", "ajouter CV", "déposer CV", "télécharger CV", etc. Si on relie un candidat à "gestion CV", dans le diagramme global, ce ne serait pas possible côté "employeur" car un employeur ne peut pas "déposer un CV". C'est à cause de ce genre de situation qui j'ai un problème à décomposer mon diagramme. Pour les cas complexe "gestion compte", c'est logique de le relier au candidat ainsi qu'à l'employeur car les deux acteurs partagent les mêmes sous cas de ce cas complexe.

[goldray]

Oui logique.
Si chaque acteur à sa propre interface qui permet de consulter les offres dans ce cas vous pouvez créer deux cas d'utilisations l'un consulter offre et l'autre gérer offre.Si non vous pouvez ajouter un point d'extension au niveau du cas d'utilisation "consulter offre" dont la condition est "si employeur inscrit".

[nounouuuuu201186]

Si chaque acteur à sa propre interface qui permet de consulter les offres dans ce cas vous pouvez créer deux cas d'utilisations l'un consulter offre et l'autre gérer offre.

Pouvez-vous schématiser cette possibilité aussi bien au niveau du diagramme global ainsi que pour le diagramme détaillé?

[goldray]

La meilleure solution à mon avis c'est l'utilisation du point d'extension si votre AGL(logiciel) l'autorise si non vous pouvez utiliser une note contenant la condition "si employeur inscrit".

Est ce que l'employeur peut faite les tâches d'un candidat non inscrit ? Puisque c'est possible qu'il fasse certaines tâches telles que consulter offre ,rechercher,consulter conseils etc.
Si oui ,donc fait une généralisation entre les deux et tous sera réglé.

[nounouuuuu201186]

Bonjour @goldray
J'utilise PowerAMC pour réaliser mes diagrammes. Avez-vous une idée comment ajouter des points d’extensions au niveau de cet outil de modélisation?
Pour ma nouvelle version du diagramme, je ne sais pas si les "include" ainsi que les "extend" sont corrects?
J'ai enlevé l'héritage entre un utilisateur inscrit et non inscrit puisque j'ai ajouté le cas d'utilisation "s'authentifier".

[goldray]

Bonsoir,
Normalement il n'est pas possible avec PowerAMC ,posez votre question sur ce forum:
http://www.developpez.net/forums/f42...tils/poweramc/

Une premiére vue globale ,les diagramme m'ont apparu lisible !

Les remarques:

• Utiliser des verbes à l'infinitif au niveau des CU (exemple gérer au lieu de gestion)..

• Pourquoi vous avez supprimer candidat et employeur non inscrits ?ils doivent figurer dans le diagramme.

• Au niveau du diagramme global ,le CU "postuler" n'a pas de signification ,si il est relatif à postuler CV ,donc vous pouvez l’intégrer au sein su CU "gérer CV".

• Est ce que la postulation est payante ?

• Pour le diagramme CU détaillé gérer compte ,un candidat/employeur ne peut pas se ré-inscrire une autre fois!

• Pour le diagramme CU détaillé gérer offre ,est ce qu'il a une différence entre publier offre et déposer ?

• Pour le diagramme CU détaillé gérer candidat,quel est le rôle du CU rejeter candidat ?

Bonne chance.

[nounouuuuu201186]

Utiliser des verbes à l'infinitif au niveau des CU (exemple gérer au lieu de gestion)..

Il y a un ami qui m'a conseillé d'utiliser un nom au lieu d'un verbe pour les cas d'utilisation complexes. Cela n'existe pas en UML? Personnellement, j'ai tenu son conseil en considération sans vérifier cette information.

Pourquoi vous avez supprimer candidat et employeur non inscrits ?ils doivent figurer dans le diagramme.

Par exemple, le fait de relier "consulter candidature" à "s'authentifier" montre bien, à mon avis qu'on est en train de parler d'un candidat inscrit. J'ai pensé que cela est suffisant. NON?

Au niveau du diagramme global ,le CU "postuler" n'a pas de signification ,si il est relatif à postuler CV ,donc vous pouvez l’intégrer au sein su CU "gérer CV".

La postulation comprend obligatoirement un CV et comme option une LM. Mais, je pense maintenant à l'intégrer au niveau du cas d'utilisation "gestion CV".

Est ce que la postulation est payante ?

Non. Le candidat ne paye rien. Mais, l'employeur oui.

Pour le diagramme CU détaillé gérer compte ,un candidat/employeur ne peut pas se ré-inscrire une autre fois!

Donc, je dois enlever le cas d'utilisation "s'inscrire" et l'introduire dans le diagramme global?

Pour le diagramme CU détaillé gérer offre ,est ce qu'il a une différence entre publier offre et déposer ?

J'ai pensé que l'employeur ajoute une offre et peut la vérifier avant la publication définitive.

Pour le diagramme CU détaillé gérer candidat,quel est le rôle du CU rejeter candidat ?

J'ai pensé qu'in y a une possibilité pour accepter le candidat ou le rejeter. Le modérateur, lui, décide qu'un candidat ou un employeur peut rejoindre le système. C'est juste ma pensée.

Et pour les autres diagrammes détaillés, je n'ai pas pu les joindre dans mon message précédent car le nombre de fichiers à joindre est limitée à 5. Voilà, je peux les joindre maintenant pour profiter de vos remarques.
Vraiment MERCI @goldray pour vos remarques.

[goldray]

Bonjour,

• Les acteurs candidats et employeur non inscrits doivent figurer (à mon avis) puisque se sont les seuls qui puissent s'inscrire.
• si la postulation est payante donc l'employeur doit avoir un CU nommé "payer ..." ...
• Pour gérer annonces ,approuver et retirer seront fait après la consultation ,donc extend avec consulter(de même pour gérer employeur et postulation).

[nounouuuuu201186]

Bonjour,
j'ai un souci concernant l'utilisation de <<include>> dans mes diagrammes.
D'après la discussion use case include, et en particulier l'intervention de @bruno_pages:

UC1 --<<include>>--> UC2 veut dire que l'exécution de UC1 implique obligatoirement celle de UC2

je veux savoir si mon utilisation de <<include>> est correcte?
J'espère que @bruno_pages intervient dans cette discussion pour nous donner son avis comme étant expert de domaine.

[goldray]

Bonjour,
L'inclusion est utilisée dans deux cas:

• Factoriser des traitements communs(exemple le cas de s'authentifier au niveau du diagramme global).
• Décomposer une tâche complexe (exemple gérer offre sera décomposée en deux sous tâches consulter offre et ajouter).

Tandis que l'extension est généralement soumise à une condition (point d'extension).

J'ai imaginé que lors de consultation des annonces(par exemple) le modérateur va manipuler des boutons pour chaque annonce tels que approuver ,rejeter,modifier,supprimer(exemple) .Dans ce cas le traitement est conditionnel d'où l'utilisation d'extend.