-1

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

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

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

这是我当前的用例图:

http://ubuntuone.com/0zDw9kEbj1BwtXjnCtxdwC

我的问题是:

  • 可以独立访问扩展或包含的用例吗?如果我按照屏幕截图中的方式进行操作,是否可以AddProspectiveIngredient在不通过CreateRecipe用例的情况下使用?对于包含的用例,同样的问题。

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

在 (1) 中,一切都与参与者有关,我对这个答案非常满意,因为我现在明白扩展用例的主要参与者将不可避免地成为扩展用例的主要参与者的子类。

(2) 解决扩展和包含用例的可重用性,但不一定与参与者相关联。这是关于在其他用例中重用它们。所以如果我有两个用例CreateRecipe(a)和AddIngredientToDatabase(b),其中 (b) 扩展了 (a),我还可以使用 (b) 扩展第三个用例吗?在这里,我也收到了我的回答,他们可以而且应该被重用。

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

如果我被告知核心问题是什么,我也很乐意稍微改写它们以保持它们的开放性。关于这些主题的更多答案和评论对我来说仍然很有趣。

4

1 回答 1

0

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

他们应该是。这是一种很好且正确的风格。用例是在一个或多个参与者和系统之间进行的一些活动。您应该尽量不要在这里显示一些与用户无关的内部操作。此处无法显示用户不可见的任何内容。USER案例,还记得吗?

所以,这里没有内部结构。

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

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

所以,我不知道你采访客户的情况如何,但你的用例图看起来几乎是正确的。只有 AddProspectiveIngredient 用例应该获得它的用户或更多。

于 2014-02-23T22:09:43.767 回答