扩展用例帮助！ UML答案

【问题标题】：Extended use case help! UML扩展用例帮助！ UML
【发布时间】：2018-02-23 03:55:34
【问题描述】：

在我的用例图中，有一个名为“查看玩具”的用例，其中成员和访问者都可以查看玩具。但是，扩展用例“购买玩具”只能由会员完成。我应该将它们作为单独的用例吗？

【问题讨论】：

【解决方案1】：

只需避开<<extend>>（别管它）。当你离开它时，你的用例仍然有意义，不是吗？更重要的是，现在很清楚，“View Toy”可以由两个演员执行，而“Purchase Toy”只能由成员执行。 <<extend>>（如<<include>>）的含义是关于系统实现中的可选性。不是关于“呼叫”行为。

如果您碰巧需要<<extend>>，您可以将约束附加到连接器，告知它仅对成员可用。

【讨论】：

您也许还可以让购买玩具包括查看玩具（大概是 IRL），其中会员演员与前者相关联，而访客和会员演员与后者相关联。
@BobRodes 你可以这样做。但我想如果没有<<include>> 它也是正确的。使用<<include>> 会进行一些功能分解，这不是用例综合的目标。每个用例本身必须是完整的。包括/分机。是关于可选性的（例如您可以将乐高零件放入系统中以使其更方便）。
我不确定我是否在关注你，Thomas。首先，包含与可选性无关，对吗？扩展是。然后，如果有时当您查看某件商品时会购买它，有时不会，但您总是会在购买时查看该商品（我正在考虑添加到购物车类型的场景），那么拥有两个不是有意义吗？购买用例包含视图的用例？
@BobRodes View 是一个独立的 UC。如果 Buy UC 需要您查看它的前置条件，则设置后置条件 itemViewed 并在 Buy UC 中使用它。 “功能性” i/e 是对连接器的错误使用。不幸的是，OMG 没有很好地解释这一点。
您的意思是，一个包含的 UC 必须始终以包含的 UC 的身份运行，并且不能在某些情况下独立运行，而在其他情况下不能被另一个 UC 包含。那是对的吗？如果是这样，您介意将我指向规范中解释不佳的地方吗？你让我很好奇。