如何在 UML 用例图中显示计算机视觉和 AR
我的系统同时使用增强现实和计算机视觉， 第一个功能是：用户参与者可以扫描特定对象，并且计算机视觉应该识别它。 第二个功能是：用户演员可以使用增强现实查看特定地点。
每个功能都是一个与用户相关的用例，但我是否也将它们与某种人工智能参与者相关联？如果是的话，合适的方法是什么？ 我只是说“计算机视觉系统”和“增强现实系统”吗？
My system uses both Augmented reality and computer vision,
The first feature is: The user actor can scan a specific object and the computer vision should recognize it.
The second feature is: The user actor can view a specific place using the augmented reality.
Each feature is a use case connected to the user, but do I also connect them to some sort of AI actors? and if so what is the suitable way to do it?
Do I just say "Computer vision system", and "Augmented reality system" ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
功能还是用例？
这是一个很好的开始。但是，这里存在一个关键的误解：
这是两个不同的概念。当然有一些重叠：可以用目标来描述一些更高的功能。例如，可以期望ERP具有会计，仓库管理和销售管理功能。
但是功能更为笼统：它还可以描述用户无法直接观察到的技术功能（例如备份），与特定的行为（例如多语言用户界面）无直接相关的功能或更详细的功能（例如，日期选择功能）
如果您使用功能，则可以考虑非uml技术，例如a 特征树或 user-story映射用用户故事构建的树）。
图中带有用例的大图
，灯泡似乎表明了系统提供的，而不是用户想要做的。如果您想用用例显示大型图片，则需要将气泡与用户目标联系起来：
这可能看起来像是一场不必要的哲学辩论。但这不是。因为用例的主要好处是一种面向目标的方法。正确地构建问题或期望，可以使您可以在替代方案上更具创造力的思考，而不是在预先构想的解决方案中锁定您。
演员
提出了另一个问题：这些参与者是否自主和独立系统，它们对用户很重要吗？还是他们只是实施详细信息？
正式地，参与者在系统外部，此外，用例不应取决于系统的内部结构。因此，如果计算机视觉和虚拟现实系统实际上是库，组件，系统的子系统，则它们不应出现在图中。
其次，用例应为参与者的价值带来可观察的结果。如果外部系统取决于您的系统，并且没有自己的价值，则用例结果对此系统不可能有价值。例如，DBM通常被视为候选参与者，但不要通过此测试：没有主系统的DBM将是没有用的。如果系统不是独立的自主，则只需将其从图表中删除，以使事情变得简单。
最后，系统演员对其他演员重要吗？如果如果外部系统操作器介入，则对您的人类用户没有任何影响，请保持简单，尽管可以，但不会显示系统演员。因为再说一遍，依靠外部系统而不是要求，这是实施选择。
Feature or use-case?
This is a good start. However, there is a key misconception here:
These a two different concepts. There is of course some overlap: some higher level capabilities can be described in terms of goals. For example, an ERP can be expected to have accounting, warehouse management and sales administration features.
But features are more general: it can also describe technical capabilities that are not directly observable by the user (e.g. backup), capabilities that are not directly related to a specific set of behaviors (e.g. multilingual user interface), Or which are much more detailed (e.g. date picking feature)
If you're on features, you may consider non-UML techniques, such as a feature tree, or user-story mapping (which is a kind of feature tree constructed with user-stories).
The big picture with use-cases
In your diagram, the bulbs seem to show that the system offers, and not what the user wants to do. If you want to show the big-picture with use-cases, you need to relate the bubbles with user goals:
This might look like an unecessary philosophic debate. But it is not. Because the main benefit of use-cases is a goal-oriented approach. Framing the problem or the expectations correctly, may allow you to think more creatively at alternatives instead of locking you early in a pre-conceived solution.
The right boundaries
The actors raise another question: are these actors autonomous and independent systems and do they matter to the user? Or are they just implementation details?
Formally, actors are external to the system, and moreover, the use-case should not depend on the internal structure of the system. So if the computer vision and the virtual reality system are in fact libraries, components, sub-systems of your system, they should not appear in the diagram.
Secondly, use-cases should offer observable result of value for actors. If the external system is dependent on your system and has no value on its own, then the use-case results cannot be of value to this system. For example, a DBMS are often viewed as candidate actors, but do not pass this test: the DBMS without the main system would be useless. If the system is not independent an autonomous, just remove it from the diagram to keep things simple.
Lastly, is, does the system actor matter to the other actors? If it makes no difference for your human users if an external system-actor intervenes, keep it simple and do not show the system-actor although you could. Because then again, it's more an implementation choice to rely on an external system than a requirement.
您表示的方式是常见的做法。所谓的主要演员（这是从所考虑的系统中接收附加值的人）放在左侧，所谓的次要参与者（仅参加和/或支持用例）将正确的。取决于加州大学图的读者将是谁的外观会很有意义。如果您向某些客户展示它，他们可能对此不感兴趣。但是对于系统设计师来说，这将是一些重要的信息。
The way you denoted it is common practice. The so-called primary actor (which is who receives the added value from the system under consideration) is placed to the left and the so-called secondary actors (which only take part in and/or support the use case) are placed to the right. Depending on who the reader of the UC diagram will be their appearance will make sense or not. If you present it to some customer they are likely not interested in IT blurb. But for system designers it would be some important information.