Discussion :

[jwheatp]

Bonjour,

J'ai trouvé sur le web quelques exemples de diagrammes de cas d'utilisation qui contredisent ma compréhension des relations include/extend.

Déjà, include/extend tels que je les comprends :

Include: An including use case calls or invokes the included one. Inclusion is used to show how a use case breaks into smaller steps. The included use case is at the arrowhead end.

Extend: An extending use case adds goals and steps to the extended use case. The extensions operate only under certain conditions. The extended use case is at the arrowhead end.

(Source)

Les exemples que je ne comprends pas :


1. Dans un livre, il y a l'exemple d'un système qui est une agence de voyage. L'auteur y met - entre autres - deux cas d'utilisation : Réserver un voyage et Annuler la réservation. Et il met une relation include entre les deux (pointant vers le deuxième). Et je ne comprends pas pourquoi : on annule pas la réservation dès qu'on réserve un voyage.
2. Sur cet exemple, le deuxième schéma. Dans la première réponse apportée, la personne contredit la relation extend entre Login et Reset Password ;

A part si ces deux exemples sont faux, il semble qu'il y a une subtilité que je n'ai pas comprise sur ces deux relations Quelqu'un peut m'éclairer ?

[bruno_pages]

1. Dans un livre, il y a l'exemple d'un système qui est une agence de voyage. L'auteur y met - entre autres - deux cas d'utilisation : Réserver un voyage et Annuler la réservation. Et il met une relation include entre les deux (pointant vers le deuxième). Et je ne comprends pas pourquoi : on annule pas la réservation dès qu'on réserve un voyage.

oui, aucun de ces deux UCs n'inclue l'autre

on pourrait penser que Annuler la réservation - - - - -<<extend>>- - - -> Réserver un voyage, mais comme l'annulation peut être faite à postériori alors qu'on est plus dans la phase/UC de réservation ce n'est pas le cas, simplement le fait qu'il y est eu une réservation (non encore annulée) est un pré requis pour son annulation

2. Sur cet exemple, le deuxième schéma. Dans la première réponse apportée, la personne contredit la relation extend entre Login et Reset Password ;

la personne a raison de dire que reset password n'est pas une extension du login :

• comme la personne le dit dans sa modélisation il est préférable que l'acteur qui se logue et l'acteur une fois logué ne sont pas le même acteur, un acteur représente un rôle et les deux rôles sont différents, puisqu'il est impossible pour l'acteur non logué de faire le reset du mot de passe alors ce reset ne peut donc être une extension du login
• même s'il y a qu'un acteur permettant de tout faire il n'y a pas de raison sémantique que le reset du mot de passe soit une extension du login, sinon l'ensemble des UCs pouvant être faits une fois logué seraient eux aussi des extensions de l'UC login qui devient n'importe quoi. Par contre toujours avec un seul acteur, la bonne exécution de l'UC login est une pré-condition d'autres UCs comme par exemple le reset du mot de passe

En dehors de cela à noter qu'un UC doit avoir une vraie plus value, et d'aucuns considèrent que le login n'en a pas assez pour être considéré comme étant un UC

[jwheatp]

Merci pour votre réponse !

on pourrait penser que Annuler la réservation - - - - -<<extend>>- - - -> Réserver un voyage, mais comme l'annulation peut être faite à postériori alors qu'on est plus dans la phase/UC de réservation ce n'est pas le cas, simplement le fait qu'il y est eu une réservation (non encore annulée) est un pré requis pour son annulation

En effet. Quand vous parlez de prérequis, vous le modéliseriez donc avec une condition entre l'acteur et l'UC "Annuler la réservation" ?

- comme la personne le dit dans sa modélisation il est préférable que l'acteur qui se logue et l'acteur une fois logué ne sont pas le même acteur, un acteur représente un rôle et les deux rôles sont différents, puisqu'il est impossible pour l'acteur non logué de faire le reset du mot de passe alors ce reset ne peut donc être une extension du login
- même s'il y a qu'un acteur permettant de tout faire il n'y a pas de raison sémantique que le reset du mot de passe soit une extension du login, sinon l'ensemble des UCs pouvant être faits une fois logué seraient eux aussi des extensions de l'UC login qui devient n'importe quoi. Par contre toujours avec un seul acteur, la bonne exécution de l'UC login est une pré-condition d'autres UCs comme par exemple le reset du mot de passe

En dehors de cela à noter qu'un UC doit avoir une vraie plus value, et d'aucuns considèrent que le login n'en a pas assez pour être considéré comme étant un UC

En fait, dans mon esprit "Reset password" c'était "J'ai oublié mon mot de passe", qui peut être fait sans être loggé, il y avait peut être déjà là une confusion dans le stackoverflow de départ. Dans tous les cas je comprends mieux et je suis d'accord avec votre second point et votre phrase de conclusion C'est plus clair dans mon esprit, merci !

[bruno_pages]

En effet. Quand vous parlez de prérequis, vous le modéliseriez donc avec une condition entre l'acteur et l'UC "Annuler la réservation" ?

non car l'acteur n'est pas spécifique de chacune des réservations

la pré-condition n’apparaît pas dans le diagramme ou alors sous forme d'une note, la précondition est indiquée dans la description textuelle associée à l'UC "Annuler la réservation", de même que d’éventuelles post-conditions. Un UC n'est pas qu'un ovale avec un nom dans un diagramme, un UC doit avoir sa description textuelle

En fait, dans mon esprit "Reset password" c'était "J'ai oublié mon mot de passe", qui peut être fait sans être loggé, il y avait peut être déjà là une confusion dans le stackoverflow de départ.

ah ok, mais même dans ce cas l'UC "Reset password" n'est toujours pas une extension de l'UC login, il s'agit de 2 UC indépendants, ce n'est pas parce qu'il y aurait une IHM permettant de se loguer ou de demander le reset que ce dernier fait parti du login

un exemple d'UC d'extension de l'UC de login est l'UC gérant le cas ou le couple nom/mot de passe est invalide