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

首先＆＃34;作为一般建议＆＃34;：

＆＃34;不要浪费你的时间通过询问＆＃34;我应该添加吗？＆＃34;。因为你   是唯一能说出这个的人吗？只要问问自己：显示或   将其添加到您的图表中，您将获得什么样的好处？

建模意味着显示隐藏细节的重要概念。你是   谁会识别什么是重要的，什么是详细的。因为你将实施系统而让你的手弄脏。

其次＆＃34; Techically＆＃34;

扩展意味着＆＃34;执行用例/场景＆＃34; 是可选的还是有条件的。

所以如果＆＃34;预处理查询＆＃34; [我不知道它是什么    手段。无论是什么，都可以根据条件执行[   假设当x条件为真时在＆＃34;进行查询＆＃34;用例，然后   ＆＃34;预处理查询＆＃34;用例/场景将被执行]，技术上是真的使用扩展关系。 所以你可以做   你自己的判断。

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

尽可能不要使用＆＃34; include＆＃34;或＆＃34;延伸＆＃34;   关系。它们使您的用例和图表更加复杂。

首先使用您的用例作为文本然后如果您发现＆＃34;相同   场景＆＃34;在您的用例中[repating]将它们作为单独的用例提取。使用   ＆＃34;包含＆＃34; 将这些常见用例/方案附加到主要用途   例/场景。使用扩展＆＃34;关系＆＃34;每当你找到/发现新的   主要用例可选择执行的重要场景。

我的个人想法：

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

主要问题是＆＃34;我应该在我的用例图中显示它＆＃34;。所以你应该问，谁会阅读我的用例图？或者为什么我创建这样的图表？根据您的背景做出自己的判断。务实。

更多信息：

用例是＆＃34;文本故事＆＃34;一些演员使用系统来实现目标。在您的情况下，您的演员是智能手机用户。

请问问自己，用户想要对您的系统做些什么？

拍照。 [合理合理]
键盘类型 [声音不好]：为什么他/她键入键盘？她/他的主要目标是什么？也许你的意思是搜索图片...在那种情况下＆＃34;键入键盘＆＃34;用例不是一个好用的候选者。要搜索图片，他可能会用键盘图片名称来编写。但打字键盘不是他/她的主要目标：它是＆＃34; 按文字搜索图片＆＃34;的一部分。用例。
说话？他为什么说话？录制他的声音？或用语音搜索图片。再次主要目标？我认为您的意思是用户可以通过语音搜索图片。[按语音搜索用例]
提出查询：查询是＆＃34;开发人员＆＃34;术语。当然，在实现系统时，您需要对数据库进行查询。但用例不适用于开发。它们用于捕获用户需求。但是，如果在您的用例中，您在＆＃34;查询＆＃34;的许多用例中执行相同的步骤。根据用户的观点，在＆＃34; include＆＃34;中使用它。关系是OKEY
对待查询：[将语音查询转换为文本查询]因此它不是用例。它可能是＆＃34;按语音搜索＆＃34;的一部分：当您编写＆＃34;按语音搜索＆＃34;用例文本：

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

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

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

2 个答案: