2015-08-01 3 views
-1

Dans mon diagramme de cas d'utilisation, il y a un cas d'utilisation appelé "Voir le jouet", où le membre et le visiteur peuvent voir le jouet. Cependant, le cas d'utilisation étendu «Achat de jouets» ne peut être effectué que par un membre. Devrais-je les avoir comme cas d'utilisation séparés?Aide en cas d'utilisation étendue! UML

Répondre

1

Il suffit d'éviter le <<extend>> (laissez-le). Quand vous en partez, vos cas d'utilisation ont toujours du sens, n'est-ce pas? D'autant plus que c'est clair maintenant, que "Regarder Jouet" peut être préformé par les deux acteurs alors que "Acheter Jouet" ne peut être fait que par le membre. La signification de <<extend>> (comme <<include>>) concerne l'optionalité dans la mise en œuvre du système. Pas sur un comportement "d'appel".

Si vous avez besoin de <<extend>>, vous pouvez attacher une contrainte au connecteur indiquant qu'il n'est disponible que pour un membre.

+0

Vous pourriez peut-être aussi acheter Jouet comprend Voir Jouet (probablement il fait IRL), avec un acteur membre lié à l'ancien et à la fois acteur invité et membre lié à ce dernier. – BobRodes

+0

@BobRodes Vous pouvez le faire. Mais je suppose que sans le '<>' ce serait correct aussi. L'utilisation du '<>' impose une décomposition fonctionnelle qui n'est pas l'objectif d'une synthèse de cas d'utilisation. Chaque cas d'utilisation doit être complet en soi. Incl./Ext. sont sur l'optionalité (comme les pièces de Lego que vous pouvez mettre dans le système pour le rendre plus pratique). –

+0

Je ne suis pas sûre de te suivre, Thomas. D'abord, les inclusions ne concernent pas l'optionalité, n'est-ce pas? Les extensions sont. Ensuite, si parfois, quand vous regardez un article, vous l'achetez, et parfois non, mais vous verrez toujours un article lorsque vous l'achetez (je pense ajouter des scénarios de type panier), cela n'a-t-il pas de sens d'avoir deux cas d'utilisation où le cas d'achat inclut la vue? – BobRodes