如何在UML用例图中展示计算机视觉和增强现实？

Question

如何在UML用例图中展示计算机视觉和增强现实？

computer-visionumlaugmented-realityuse-caseuse-case-diagram

4

我的系统同时使用增强现实和计算机视觉技术。

第一个功能是：用户可以扫描特定物体，计算机视觉技术能够识别出该物体。

第二个功能是：用户可以使用增强现实技术查看特定地点。

每个功能都是与用户相关的用例，但我是否还需要将它们与某种 AI（人工智能）模块连接起来？如果需要，最好的方式是什么？我只需称之为 "计算机视觉系统" 和 "增强现实系统" 吗？

- manar Aldhafyan

以上内容对我来说看起来不错（除了拼写错误）。 - qwerty_so

1

我必须说，这是我见过的拼写“虚拟现实系统”最有趣的方式。但是说真的，用例不是关于功能，绝对也不是关于你的系统内部的技术系统。用例是关于用户可以通过你的系统完成的大事情，这些事情对他们有附加价值。在用例中，该系统应该是一个黑盒子。除非它们是你的系统与其他第三方系统通信的其他辅助角色，否则不应该有次要演员。 - Geert Bellekens

Manar，您能告诉我们计算机视觉和虚拟现实是独立自主的系统还是只是您的系统（子系统、组件、库等）的实现细节吗？ - Christophe

顺便问一下，演员的目标仅仅是扫描一个对象吗？还是扫描只是实现更大目标（例如：识别一个对象，将对象放置在虚拟现实中等）的步骤？ - Christophe

2个回答

1

您所描述的方式是常见的做法。所谓的主要参与者（即从考虑中的系统中获得增值的人）放置在左侧，而所谓的次要参与者（仅参与和/或支持用例）放置在右侧。根据UC图的读者是谁，它们的外观可能有意义，也可能没有。如果您向某些客户展示它们，他们可能对IT术语不感兴趣。但对于系统设计师来说，这将是一些重要信息。

- qwerty_so

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Christophe · Accepted Answer

特性还是用例？

这是一个不错的开端。然而，这里存在一个关键误解：

特性是软件提供的功能或能力，因为它们有助于用户实现某种目的而受到用户重视。特性通常与用户故事相对应。
用例代表系统使用者的目标，对应于一组行为和与用户的交互，而不涉及系统的内部结构。

这是两个不同的概念。当然，它们之间有一些重叠：一些更高级别的功能可以用目标来描述。例如，ERP可预期具有会计、仓库管理和销售管理功能。

但特性更为通用：它还可以描述用户无法直接观察到的技术能力（例如备份）、与特定行为集不直接相关的能力（例如多语言用户界面），或者更详细的功能（例如日期选择功能）

如果您正在考虑特性，则可以考虑非UML技术，例如特性树或用户故事映射（这是一种用用户故事构建的特性树）。

用例的大局观

在您的图表中，灯泡似乎显示了系统提供的内容，而不是用户想要做的事情。如果您想展示用例的全貌，则需要将气泡与用户目标相关联：

用户只想扫描物体吗？还是这种扫描只是实现更大目标的一步，例如进行清点、识别和订购备件或填充虚拟世界。
用户只想在VR中查看一个地方吗？还是期望更为雄心壮志，例如购买在特定地方看起来不错的产品？

这可能看起来像一个无关紧要的哲学辩论。但不是这样的。因为用例的主要优势是面向目标的方法。正确地构思问题或期望可能使您能够更有创造力地考虑替代方案，而不是过早地将您锁定在预设解决方案中。

正确的边界

演员们提出了另一个问题：这些演员是否是自治且独立的系统，并且它们对用户是否重要？还是它们只是实现细节？

从形式上讲，演员是系统外部的，而且用例不应取决于系统的内部结构。因此，如果计算机视觉和虚拟现实系统实际上是您系统的库、组件和子系统，则不应出现在图表中。

其次，用例应该为参与者提供可观察到的价值结果。如果外部系统依赖于你的系统并且本身没有价值，那么用例结果对该系统就没有价值。例如，DBMS经常被视为候选参与者，但是未通过此测试：没有主系统的DBMS将是无用的。如果系统不是独立的自主的，则从图表中删除它以保持简单。

最后，系统参与者是否对其他参与者有影响？如果外部系统参与者的干预对您的人类用户没有影响，则保持简单，不要显示系统参与者，尽管您可以这样做。因为再次，依赖外部系统更多是一种实现选择而不是要求。