我正在基于以下场景创建一个用例图:
有一个移动应用程序，它将数据传递给web服务器/数据库。另一方面，web服务器向移动应用程序发送数据。
所以我有两个问题:
-
发送到应用程序的数据仅为该智能手机/用户的个人数据。那么，将服务器/数据库显示为与特定用例连接的外部系统参与者有意义吗?
-
用例(对于移动应用程序)是否需要"显示有关某些内容的信息"或"刷新数据"?因为我认为它们对于业务逻辑来说是不必要的。你觉得呢?
谢谢你的建议!
发送到应用程序的数据仅用于此智能手机/用户。那么，将服务器/数据库显示为与特定用途相关联的外部系统参与者例?
仅当服务器/数据库确实是一个外部系统，您的系统与之通信时。如果不是，那么它就不能是一个参与者，并且您应该强制创建一个额外的UML建模来澄清整个系统结构(组件图+序列)。
数据是独立的这一事实与这个决定无关。:)
是用例(用于移动应用程序)，如"显示关于的信息"有必要"刷新数据"吗?因为我认为他们不是业务逻辑所必需的。你觉得呢?
如果你正在构建这个移动应用程序，并且这些是实现的需求，那么你绝对应该捕获它们作为用例。
你所说的"它们对业务逻辑来说不是必需的"是什么意思?
你的系统的作用域是什么?(手机应用程序，手机应用程序+服务器/数据库或其他东西)?
UPDATE(清理系统范围后)
我们正在构建移动应用程序和数据库。所以我们不只是从那里获取数据并发送数据。我们对整体进行建模系统
作用域现在被清除- database/server不能是参与者，因为它是作用域的一部分。我看到的唯一角色是手机应用的用户。
当用户是演员，应用是演员时系统我不知道如何描述用例，因为我认为我必须在uce案例描述中提到数据被发送到哪里服务器等…
你不必把所有的东西都放在用例描述中，我将很快回到这一点。
例如:一个用例是关于拍摄照片并将其发送到服务器- -
那么，这个UC有什么问题?演员是移动应用程序用户，用例是"上传图片"(它可以选择包括拍照)。
我认为您混淆了您试图将所有关注点放在用例模型中的几个关注点的混合，而这是不可能的。
因此，我建议您将关注点(系统的各个方面)分开，制作以下图表:
- 业务级别:活动图显示应用 的整体使用/业务工作流
- 一个用例模型捕获请求
确保使这个模型简单，并且从Actor的角度来看。只需确定Actor可以执行的一小组有意义的交互(而不是低级别的)。例如:"上传照片"，"刷新数据"可能是一些实体UCs
- (可选)概念/数据模型(清理相关数据结构)
- 系统结构通过组件/部署图(这里你显然有至少3个组件:移动应用程序，WEB服务器(或任何接收来自移动应用程序的请求)和数据库
- 通信机制 -使用组件的序列图
现在您需要一些"胶水"来将不同的概念联系起来——对于每个用例，使用组件图中的元素(当然是+参与者)，制作一个序列来显示它是如何工作的。
关键在于"打开"用例，并根据系统结构元素显示它们的内部实现。