我目前正在刷新/改变我在软件开发方面的知识，因为我很快就会在这个领域工作。我们在大学学到了很多关于UML图和编码的知识，但我从来没有在一个真实的项目中将它们全部整合在一起。因此，我开始在Grails中创建一个测试Web应用程序，我想从需求分析和用例开始，使其保持接近现实。
我的网络应用应允许用户分享食谱，查找食谱和查看其他用户的食谱。每个食谱都有很多成分，不仅仅是字符串，而是实体，因此卡路里，脂肪，蛋白质和碳水化合物可以用来自动计算某种食谱的营养成分。
消费者或营养专家可以将一种成分添加到数据库中。如果它是由消费者创建的，那么它只是一种“预期”成分，这意味着它必须由管理员验证才能成为“适当的”成分 - 否则它被标记，例如，红色文字颜色。
这是我目前的用例图：
http://ubuntuone.com/0zDw9kEbj1BwtXjnCtxdwC
我的问题是：
AddProspectiveIngredient用例的情况下使用CreateRecipe吗？包含用例的相同问题。编辑：我认为这不是this question的副本。在链接问题（1）中，我问是否必须使用相同的actor来扩展和包含用例，如扩展或包含用例。然而，在这个答案（2）中，我只是询问用例之间的重用。
在（1）中，它完全是关于actor的，我对this answer非常满意，因为我现在明白扩展用例的主要角色将不可避免地成为主要角色的主要角色。扩展用例。
（2）解决了扩展和包含用例的可重用性，但不一定与actor有关。它是关于在其他用例中重用它们。因此，如果我有两个用例CreateRecipe（a）和AddIngredientToDatabase（b），其中（b）扩展（a），我还可以用（b）扩展第三个用例吗？在这里，我也收到了答案，他们可以而且应该重复使用。
也许问题看起来很相似，因为我在同一天用相同的例子创建了它们，答案都提到了演员，这使得它们看起来像是重复的。由于他们都得到了回答，我对这两个答案感到满意，为什么要将这些问题关闭为“过于宽泛”或“重复”？如果用不同的答案成功回答，它怎么可能过于宽泛或重复？
如果我被告知核心问题，我也很乐意稍微改写它们以保持它们开放。关于这些主题的更多答案和评论对我来说仍然很有趣。答案 0 :(得分：0)
可以独立访问扩展或包含的用例吗？
他们应该是。这是一个很好的和正确的风格。用例是一个或多个参与者和系统之间进行的一些活动。您应该尽量不在这里显示一些与用户无关的内部操作。这里可以显示用户看不到的任何内容。用户案例，还记得吗？
所以，这里没有内部结构。
您可以在群组中收集一些案例 - 子系统。但它不是内部结构，它们不是IT系统，它们只是活动的共同主题，对用户来说是显而易见的。这些子系统应该至少具有通用的UI风格。
对于可供用户使用的逻辑，可以在其他图表上显示。在这个级别上可以存在许多图表 - 状态机，活动，时间。但是也不要试图在用例图上显示进程。
所以，我不知道你对客户进行了多少采访，但你使用案例图看起来几乎是正确的。只有AddProspectiveIngredient用例才能获得其用户或更多用户。