UML用例图：访问包含或扩展的用例

我目前正在更新/改变我在软件开发方面的知识，因为我很快就会在这个领域工作。我们在大学里学到了很多关于UML图和编码的知识，但我从来没有在一个真正的项目中把它们结合在一起。因此，我开始在Grails中创建一个测试web应用程序，我想从需求分析和用例开始，让它更接近现实

我的web应用程序应该允许用户共享食谱、查找食谱以及查看其他用户的食谱。每个食谱都有许多成分，这些成分不仅仅是字符串，而是实体，因此可以使用卡路里、脂肪、蛋白质和碳水化合物来自动计算某个食谱的营养成分

可以由消费者或营养专家将成分添加到数据库中。如果它是由消费者创建的，则它只是一种“预期”成分，这意味着它必须经过管理员验证才能成为“适当”成分——否则它会被标记，例如红色文本颜色

这是我当前的用例图：

我的问题是：

• 可以独立访问扩展或包含的用例吗？如果我按照屏幕截图中的方式操作，是否可以使用

  addprospectivecomponent

  而不必查看

  CreateRecipe

  用例？对于包含的用例，同样的问题

编辑：我不认为这是重复的。在链接的问题（1）中，我询问是否必须使用与扩展或包含用例相同的参与者来扩展和包含用例。然而，在这个答案（2）中，我只询问用例之间的重用

在（1）中，这都是关于参与者的，我对此非常满意，因为我现在了解到，扩展用例的主要参与者将不可避免地是扩展用例的主要参与者的子类

（2） 解决了扩展用例和包含用例的可重用性，但不一定与参与者相连。它是关于在其他用例中重用它们。因此，如果我有两个用例

CreateRecipe

（a）和

AddIngredientToDatabase

（b），其中（b）扩展了（a），我还可以用（b）扩展第三个用例吗？在这里，我也得到了我的回答，它们可以而且应该被重用

也许这些问题看起来很相似，因为我在同一天用同一个例子创建了它们，答案都提到了演员，这让它们看起来像是重复的。既然这两个问题都得到了回答，而且我对这两个答案都很满意，为什么要以“过于宽泛”或“重复”来结束这些问题呢？如果用不同的答案成功地回答了它，它怎么可能太宽泛或重复

---

如果有人告诉我核心问题是什么，我也很乐意对它们稍加修改，让它们保持开放。更多关于这些主题的答案和评论对我来说仍然很有趣

可以独立访问扩展或包含的用例吗

他们应该这样做。这是一种好的、正确的风格。用例是在一个或多个参与者和系统之间进行的一些活动。您应该尽量不要在这里显示一些未连接到用户的内部操作。这里不能显示任何用户看不见的内容。用户案例，记得吗

所以，这里没有内部结构

您可以分组收集一些案例-子系统。但它不是内部结构，也不是it系统，它们只是活动的共同主题，对用户来说显而易见。这样的子系统至少应该在以后获得通用的UI样式

至于用户可以使用的逻辑，它可以显示在其他图表上。在这个级别上可以存在许多图-状态机、活动、计时。但也不要试图在用例图上显示流程

---

所以，我不知道您采访客户的情况如何，但您的用例图看起来几乎正确。只有AddProspectiveComponent用例才能获得一个或多个用户。

非常感谢您的帮助。那么，我是否理解您的意思，我应该在

消费者

和

添加预期成分

之间创建关联？这难道不意味着消费者是主要参与者吗？而且，使用现有的图表，消费者可以在不创建配方的情况下创建预期的成分？这是我主要关心的问题。不，Extend仅仅意味着一种行为是另一种行为的变体。您正在使用VP UML-将鼠标指针悬停在调色板中的扩展箭头上并阅读提示。好的，我开始更好地理解了。扩展另一个用例的用例也必须与参与者有关联？如果那是对的，我知道了。令人困惑的是，大多数在线用例教程有不同的方法，显然，按照不同的规则进行游戏。@user3025256请在这里放一些链接，好吗？只是在线教程之间的一般矛盾。有些人用名词来表示用例（）；如果参与者不代表参与者目标（“执行安全检查”），则其他人将参与者与用例联系起来。这就是为什么我在这里问，因为我不知道该信任哪一个来源。如果您知道用例指南和其他UML建模的好来源，我很乐意知道。