Discussion :

[BAUml]

Monsieur Laurent Piechocki, j'ai un problème avec votre explication du "includes" et du "extends", vis-à-vis des deux schémas que vous donnez, et je ne trouve nulle part une adresse mél valide où je puisse vous écrire.

pour l'exemple include :
imprimer le solde d'un compte n'inclut pas de consulter un compte. Consulter un compte n'est pas un cas d'utilisation constituant une sous-partie du cas imprimer le solde. Vous le dîtes d'ailleurs, on doit être dans le contexte de consultation d'un compte pour cliquer sur imprimer (si on le souhaite) et ainsi imprimer le solde. Imprimer est une extension de la consultation puisque cela nécessite d'être dans un contexte de consultation et que cela demande un traitement complémentaire facultatif (l'impression).
Par ailleurs, imprimer le ticket n'est, selon moi, pas un cas d'utilisation. C'est un traitement "système" automatique lié à la demande d'impression qui figure déjà sur le diagramme de cas.

pour le extends :
les cas d'extensions que vous présentez montrent bien la difficulté de tracer une frontière entre le lien de généralisation et l'extends. Un extends, selon moi, nécessite un traitement supplémentaire assez différents du traitement initial (une impression dans le contexte d'une consultation).
En revanche, retirer des francs (des euros maintenant c'est retirer de l'argent, rien de plus, retirer des devises c'est retirer de l'argent. Il s'agit plutôt là d'un lien de généralisation.

Merci de me confirmer que nous sommes sur la même lecture de vos schémas ou bien de me préciser où nos avis divergent et pourquoi.

[dd_angel]

Voir ici pour la différence entre extends et include (c'est très clair) :
http://laurent-audibert.developpez.c...011.html#toc22

[BAUml]

Sur la page donnée en lien, le include "s'authentifier" n'est pas bon non plus.
On confond "il faut avoir fait avant" avec "il faut faire à un moment donné pendant".
Si on consulte son compte puis on retire de l'argent, on ne s'authentifie qu'une seule fois. Ce n'est donc pas un "include".

Quant à l'extension, il est dit "On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut éventuellement entraîner l’exécution de A".
Il manque (me semble-t-il) le fait que A étend *toujours* B qui indique que A a *toujours* lieu dans le contexte de B. Une extension (me semble-t-il) se suffit à elle même, elle englobe le cas étendu.

Le lien que tu donnes ne me semble pas non plus pouvoir servir de référence actuellement.

Si tu peux contacter Laurent Audibert pour l'informer, n'hésite pas Si quelqu'un peut d'ailleurs informer Laurent Piechocki, qu'il n'hésite pas, je n'y parviens pas...

[dd_angel]

Hum, je ne sais pas pour toi, mais pour moi le cas d'utilisation est indépendant du temps (pour ça, il faut faire un diagramme de séquence), donc l'exemple ici est tout à fait logique à mon sens : tu ne peux retirer de l'argent que si et seulement si tu t'es authentifier = retirer de l'argent inclus ton authentification au préalable (il n'y a pas de notion de temps ici, c'est seulement que le cas d'utilisation "retirer de l'argent" ne peut pas exister si le cas du login n'existe pas)

Pour les extensions, ce que j'en ai compris c'est que A s'étend à B de manière implicite sous condition. Et la phrase le dit bien avec les termes "peut être appelé" et "peut éventuellement entraîner", il insiste bien qu'il doit avoir une condition pour que l'extension soit possible.

Il manque (me semble-t-il) le fait que A étend *toujours* B qui indique que A a *toujours* lieu dans le contexte de B.

Pour moi, ça c'est une inclusion non ?

[bruno_pages]

oui, une extension a un caractère optionnel, contrairement à une inclusion

[BAUml]

Avoir les vitres électriques, c'est optionnel, mais pour avoir les vitres électriques il est obligatoire d'avoir une voiture. L'extension peut utiliser le mot "optionnel" dans un sens de lecture, et le mot "obligatoire" dans l'autre sens de lecture.

Par ailleurs, l'authentification n'est pas une inclusion car on ne s'authentifie pas systématiquement. "il faut l'avoir fait avant" est un concept qui prend en compte le temps justement, et ça ne se montre pas dans le diagramme de cas d'utilisation (c'est une ligne de commentaire à côté). L'authentification est ailleurs dans le diagramme.
J'ajoute en même temps qu'il n'est pas nécessaire qu'un administrateur dispose du cas d'utilisation "s'authentifier" puisqu'il s'est authentifié auparavant pour apparaître comme administrateur. Lorsqu'on sait qu'on travaille avec un administrateur, l'authentification n'est utile que pour changer de profil, de rôle ou de compte, pas pour s'authentifier en tant qu'administrateur.

S'il vous plait, confirmez ce que je dis car on embrouille tout le monde avec ce support inexact (et bien fait dans de nombreux autres aspects).

[bruno_pages]

l'exemple des vitres électriques n'est pas un très bonne idée car je n'ai pas besoin d'une voiture pour en avoir (même si je comprends ce que vous vouliez dire par là )

pour le reste je suis d'accord avec vous, l'authentification n'est pas un UC inclus :

• si on n'utilise pas des acteurs différents avant et après authentification alors celle-ci est une pré-condition pour l'exécution de certains UC
• si les acteurs sont différents alors il y a une post-condition à l'authentification indiquant que l'acteur devient un un autre acteur.

par contre on ne met pas cela dans le diagramme via un commentaire, on le met dans la description textuelle des UCs (documentation hors diagramme)

[msamou]

Je souhaite avoir votre avis sur ce cas d'utilisation. Il s'agit d'une application qui doit construire (générer) un graphe des marquages d'un réseau de Petri. Ce dernier est disponible sous un format XML. Une fois le graphe généré, on peut l'enregistrer et on peut aussi l'afficher.
J'ai mis un extend entre les cas d'utilisation Enregistrer et Générer. De même, pour les cas Afficher et Générer. Mais, dans le cas où le graphe existe déjà (générer puis enregistrer), il sera toujours possible de l'afficher indépendement du cas générer. Dois-je alors relier l'acteur(utilisateur) au cas Afficher.

Merci d'avance

[msamou]

Je chercher un document de référence sur UMl qui explique bien les includes et les extends. Je suis bien embrouillée surtout avec le "cas athentifier". Certains le considèrent comme un cas d'utilisation alors que d'autres non.