android - 用例图中扩展关系的这种用法是否正确？

Question

我正在开发一个用于图像搜索的移动应用程序

这是我的用例图

演员=智能手机用户

系统 = 客户端应用程序

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

我应该将此用例添加到我的图表中吗？

我认为这可能是这样的扩展使用 cqse

Answer 1

首先“作为一般建议”：

“不要浪费时间问“我应该添加这个吗？”。因为你是唯一可以说这个的人？问问自己：显示或添加到你的图表中，你会得到什么样的好处？

建模意味着显示隐藏细节的重要概念。您将确定什么是重要的，什么是细节。因为您将实施系统并弄脏您的手。

二是“技术”

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

所以如果“预处理查询”[我不知道它是什么意思。不管它是什么]都可以根据条件选择性地执行[假设当x条件在“进行查询”用例中为真时​​，将执行“预处理查询”用例/场景]，使用扩展关系在技术上是正确的。所以你可以做出自己的判断。

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

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

首先将您的用例写为文本然后如果您在用例中发现“相同的场景”[repating]，请将它们提取为单独的用例。使用 “包含”将那些常见的用例/场景附加到主要用例/场景中。 每当您发现/发现主要用例可选执行的新重要场景时，请使用扩展“关系”。

我的个人想法：

对我来说，您甚至不应该在图表中显示“进行查询”。[当然，在编写用例时，如果所有这 3 个用例都以相同的方式进行查询，请将其写为单独的用例，然后包括主要用例场景文本这个，使用包含关系是节省时间的。这并没有错。小心我说“在将用例写成文本时”]。

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

更多信息：

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

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

1. 拍照。[听起来合理]

2. Type Keyboard [sound not good] : 为什么他/她键入键盘？她/他的主要目标是什么？也许您的意思是搜索图片...在这种情况下，“键入键盘”不是用例的好候选者。要搜索图片，他可能会用键盘图片名称写。但是打字键盘不是他/她的主要目标：它是“按文本搜索图片”用例的一部分。

3. 说话？他为什么说话？录制他的声音？或用声音搜索图片。又是主要目标？我假设您的意思是用户可以通过语音搜索图片。[通过语音搜索用例]
4. 进行查询：查询是“开发人员”术语。当然，当您实现系统时，您会对数据库进行查询。但是用例不是用于开发的。它们用于捕获用户需求。但是，如果在您的用例中，您根据用户的观点在许多用例中为“查询”执行相同的步骤，则在“包含”关系中使用它是 OKEY

5. 处理查询：[将语音查询转换为文本查询]所以它不是一个用例。它可能是“通过语音搜索”的一部分：当您编写“通过语音搜索”用例文本时：

   主要场景：

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

   ...

   替代方案

   2 a) 图像搜索应用程序无法识别语音：......

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

不要忘记用例不是图表：用例图非常适合直观地提供系统主要功能概览。 用例是“文本故事”。

所以有很多方法可以在用例图中展示它们：

通常，在用例图中使用最小扩展、包含、泛化关系。不要浪费太多时间来识别用例中的关系。

好的，免费的用例资源查看 Craig Larman 在他的畅销书中的免费章节：

用例入门

Answer 2

首先，我会使用<<include>>而不是<<extend>. `<<extend>>定义扩展用例的补充和可选行为，扩展用例不需要此行为即可工作。另一方面，<<include>>显示添加到包含用例的行为。此外，由于此行为是您在make query用例中所做的一部分；只需在用例描述中描述make query即可。