如何在UML用例图中显示计算机视觉和AR

Question

我的系统使用增强现实和计算机视觉，第一个特点是:用户可以扫描特定的对象，计算机视觉应该识别它。第二个特点是:用户参与者可以使用增强现实查看特定的位置。

每个特性都是连接到用户的用例，但我是否也将它们连接到某种AI参与者？如果是这样的话，怎样才是合适的方法呢？我是说“电脑视觉系统”，还是“增强现实系统”？

​

​

Answer 1

特色还是用例？

这是一个很好的开始。然而，这里有一个关键的误解：

• 特性是由软件提供的特性或功能，因为它帮助用户达到某种目的，因此受到用户的重视。通常使用用户故事来标识功能。
• 用例使用系统表示参与者的目标()，这对应于一组行为和与用户的交互，而不引用系统的内部结构。

这是两个不同的概念。当然也有一些重叠:一些更高级别的功能可以用目标来描述。例如，可以预期企业资源规划具有会计、仓库管理和销售管理功能。

但功能更通用:它还可以描述用户无法直接观察到的技术功能(例如备份)、与特定行为集(例如多语言用户界面)没有直接关系的功能，或者更详细的功能(例如日期选择功能)。

如果您使用的是特性，可以考虑非UML技术，如特征树或用户故事映射 (这是一种用用户故事构造的特性树)。

用例的大图

在您的图表中，灯泡似乎显示了系统提供的，而不是用户想要做的。如果您想用用例显示总体情况，则需要将气泡与用户目标联系起来：

• 用户只想扫描对象吗？或者，这仅仅是为了实现一个更大的目标而进行的一步扫描，例如编制库存、识别和订购备件或填充虚拟世界。
• 用户是否只想查看VR中的某个位置？或者，人们的期望是否更加雄心勃勃，比如购买在特定地点看起来不错的产品？

这可能看起来是一场没有必要的哲学辩论。但事实并非如此。因为用例的主要好处是一种面向目标的方法。正确地设定问题或期望，可以让你更有创造性地思考替代方案，而不是将你提前锁定在预先设想的解决方案中。

正确的边界

这些行为者提出了另一个问题:这些行为者是否是自主和独立的系统，它们对用户是否重要？或者它们只是实现细节？

在形式上，参与者是系统外部的，而且用例不应该依赖于系统的内部结构。因此，如果计算机视觉和虚拟现实系统实际上是您系统的库、组件、子系统，它们不应该出现在图表中。

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

最后，系统参与者对其他参与者是否重要？如果外部系统-参与者介入对您的人类用户没有任何影响，请保持简单，尽管可以，也不要显示系统-参与者。因为，更多的是依赖外部系统而不是需求，这是一种实现选择。

Answer 2

你表示这一点的方式是常见的做法。所谓的主参与者(即从正在考虑的系统中获得附加值)放置在左侧，而所谓的次要参与者(只参与和/或支持用例)放置在右侧。取决于UC图表的读者将是谁，他们的外观将有意义或没有意义。如果你把它呈现给一些客户，他们可能对it脱口不感兴趣。但对于系统设计者来说，这将是一些重要的信息。