我正在根据以下场景创建用例图：
有一个将数据传递到网络服务器/数据库的移动应用程序。另一方面，网络服务器将数据发送到移动应用程序。
所以我有两个问题：
发送到应用程序的数据是仅针对此智能手机/用户的个人数据。那么将服务器/数据库显示为与特定用例相关的外部系统参与者是否有意义？
“显示某事物的信息”或“刷新数据”之类的用例（针对移动应用程序）是否必要？因为我认为它们对于业务逻辑来说不是必需的。你怎么看？
感谢您的想法！
【问题讨论】：
标签： mobile uml requirements use-case
发送到应用程序的数据仅是个人数据 智能手机/用户。那么将服务器/数据库显示为 与特定用途相关的外部系统参与者 案例？
只有当服务器/数据库是真正的外部系统，您的系统才能与之通信。如果不是，那么它就不能是一个参与者，你应该强制进行额外的 UML 建模，以明确整个系统结构（组件图 + 序列）。
数据是个人的这一事实与此决定无关。 :)
用例（针对移动应用）是否像“显示有关 一些东西”或“刷新数据”有必要吗？因为我认为它们不是 业务逻辑所必需的。你怎么看？
如果您正在构建这个移动应用程序，并且这些是实施的要求，那么您绝对应该将它们捕获为用例。
“业务逻辑不需要它们”是什么意思？
首先您的系统的范围是什么？ （移动应用、移动应用 + 服务器/数据库或其他）？
UPDATE（清除系统范围后）
我们正在构建移动应用和数据库。所以我们不仅仅是 从那里获取数据并发送数据。我们正在为整体建模 系统
现在范围很明确 - 数据库/服务器不能是参与者，因为它是范围的一部分。我看到的唯一演员是移动应用用户。
当只是将用户作为演员而应用程序作为演员时 系统我不知道如何描述用例，因为我认为我 必须在 uce 案例描述中提到数据被发送到 服务器等...
您不必将所有内容都放在用例描述中，我很快就会回来。
例如：一个用例是关于拍照并将其发送到 服务器--
那么，这个 UC 有什么问题？演员是移动应用用户，用例是“上传图片”（可以选择包括拍照）。
我认为您对尝试将所有问题都放在用例模型中的几个问题感到困惑，这是不可能的。
因此，我建议您将 cpncerns（系统的各个方面）分开制作以下图表：
请务必从 Actor 的角度简化此模型。只需确定 Actor 可以执行的一小组有意义的交互（不是低级别）。 例如：“上传照片”、“刷新数据”可能是一些可靠的 UCs
现在您需要一些“粘合剂”来关联不同的概念 - 使用组件图中的元素（+ 课程参与者）为每个用例制作一个展示其工作原理的序列。
重点是“打开”用例，并根据系统结构元素展示它们的内部实现。
【讨论】：