用例图中扩展关系的用法是否正确？

Question

我开发的图像搜索

移动应用这是我用例图

演员=智能手机用户

系统=客户端应用程序

查询在被发送到服务器之前在客户端被预先处理（例如，声音查询被转换为文本查询）

我应该将这个用例添加到我的图中吗？

我认为这是可能是长时间使用cqse这样

Answer 1

首先“作为一般的建议”：？

我要补充这个“不要问浪费你的时间‘’因为你 是唯一的家伙谁又能说这只是？问自己：显示或 加给你的图中，有什么样的好处，你会得到

建模意味着显示隐藏的细节重要的概念您是 了一个谁将会确定哪些是重要的，什么是细节。因为你会执行系统和让你的手变脏。

其次 “Techically”

扩展意味着 “执行用例/情景” 是可选的或有条件的。

因此，如果“pretreat查询”[我不知道它是什么 意味着什么。不管它是什么]可选地基于条件执行[ 假设当x条件在“查询”用例时为真，则 “pretreat query”用例/场景将被执行]，它在技术上是对的使用扩展关系。 所以你可以自己作出判断 。

最后：技术上正确并不意味着它是正确的。

只要有可能尽量不要使用“包括”或“扩展” 关系。它们使您的用例和图表更加复杂。

首先编写使用您的用例作为文本然后，如果您发现“相同的 方案”在您的用例中提出它们作为单独的用例。使用 “include”将这些常见使用案例/方案附加到主要使用案例/方案中。使用扩展“关系”，每当您发现/发现新的 重要场景可选由主用例执行。

我的个人想法：

对于我来说，你应该甚至不显示您的图表中的“创建查询” [当然在写用例，如果所有的这3个用例作出查询。同样的方法，把它作为一个单独的用例写出来，然后将主要的用例场景文本包括进去，使用包含关系是节省时间的。这没有什么错。小心我说“在将用例作为文本写入”时）。

主要问题是“我应该在我的用例图中展示它”。所以你应该问，谁会​​阅读我的用例图？或者为什么我创建这样的图表？根据你的情况做出你自己的判断。务实。

更多信息：

用例是使用系统实现目标“文本故事”的一些演员。 在你的情况下你的演员是智能手机用户。

那么问问自己用户想用你的系统做什么？

1. 拍照。 [声音合理]

2. 类型键盘 [声音不好]：为什么他/她键入键盘？她/他的主要目标是什么？也许你的意思是搜索一张照片......在这种情况下，“打字键盘”不是一个很好的用例。要搜索图片，他可能会用键盘图片名称来编写。但键入键盘不是他/她的主要目标：它是“搜索文本文本”用例的一部分。

3. 说吧？他为什么说？记录他的声音？或者用声音搜索照片。又是主要目标？ [通过语音搜索用例]
4. 查询：查询是“开发人员”术语。当然，当你实现你的系统时，你需要查询数据库。但用例不适用于开发。它们用于捕获用户需求。但是，如果在您的使用情况下，你根据查看用户点在很多使用情况“查询”做相同的步骤，在使用它“包含”关系是OKEY

5. 款待查询：[变换声乐查询文本查询]所以这不是一个用例。这可能是步的“语音搜索”的一部分： 当你写你的使用情况文本“语音搜索”：

   主要手段：

   1. 智能手机用户告诉画面名称的搜索语音。
   2. 图像搜索应用程序记录此语音并生成文本查询。
   3. 图像搜索应用程序执行此查询。
   4. 图片搜索应用程序显示的查询

   的结果......

   替代方案

   2）图像搜索应用程序无法识别的声音： .....

   对我来说，这甚至会增加不必要的技术细节：我们可能不会提到步骤2.请说： “图像搜索应用程序搜索名称由声音给出的图片”。 从语音生成文本查询是实现细节。您将如何实现。 但用例焦点是“用户可以使用您的应用程序做什么”。

不要忘了用例不图：用例图是给你的系统的主要功能概述视觉上刚刚好。 用例是“文本故事”。在你的使用情况

，通常用最低扩展，包括泛化关系 diagrams.Do没有浪费太多时间：

所以有很多的方式来表达他们的用例图在用例中确定 关系。

对于来自他的畅销书好，免费使用案例资源检查Craig Larman与提供的免费章节：

Use Case Primer

Answer 2

首先我会用<<include>>代替<<extend>的。 `<<extend>>为扩展用例定义了补充和可选行为，并且扩展用例不需要这种行为来使其工作。另一方面，<<include>>显示的行为是增加了到包含用例。此外，由于此行为是您在make query用例中所做的操作的一部分;只需在make query用例的描述中对其进行描述即可。