我正在根据以下场景创建一个用例图：
有一个移动应用程序将数据传递到Web服务器/数据库。另一方面，Web服务器将数据发送到移动应用程序。
所以我有两个问题：
发送到应用程序的数据仅适用于此智能手机/用户的个人数据。那么将服务器/数据库显示为与特定用例相关联的外部系统actor是否有意义？
用例（针对移动应用）是否像“显示某些内容的信息”或“刷新数据”一样必要？因为我认为它们不是业务逻辑所必需的。你觉得怎么样？
感谢您的想法！
答案 0 :(得分：3)
发送到应用程序的数据仅用于此的个人数据 智能手机/平板用户。因此，将服务器/数据库显示为一个是有意义的 外部系统actor与特定用途相关联 例
仅当服务器/数据库确实是外部系统时，系统才会与之通信。如果没有，那么它就不能成为一个actor，你应该强制进行额外的UML建模来阐明整个系统结构（组件图+序列）。
数据是个人的事实与此决定无关。 ：）
用例（针对移动应用）是否“显示有关的信息” 什么“奥德”刷新数据“必要？因为我认为他们不是 业务逻辑所必需的。你觉得怎么样？
如果您正在构建此移动应用程序，并且这些是实施的要求，那么您应该将它们作为用例进行定义。
“你对业务逻辑不是必需的”是什么意思？
首先，您的系统范围是什么？ （移动应用程序，移动应用程序+服务器/数据库或其他）？
更新（清除系统范围后）
我们正在构建移动应用和数据库。所以我们不仅仅是 从那里获取数据并发送数据。我们整体造型 系统
范围现已明确 - databese / server不能是演员，因为它是范围的一部分。我看到的唯一一位演员是移动应用用户。
当只是让用户成为演员和应用程序的时候 系统我不知道如何描述用例，因为我想我 必须在uce案例描述中提到数据被发送到 服务器等...
您不必将所有内容都放在用例描述中，我将很快回到这里。
例如：一个用例是关于拍照并发送给 服务器 - -
那么，这个UC的问题是什么？演员是移动应用程序用户，用例是“上传图片”（可选择包括拍照）。
我认为您对几个问题的混合感到困惑，您试图将所有问题都放在用例模型中，这是不可能的。
因此，我建议您将cpncerns（系统的各个方面）分开，制作以下图表：
请务必从Actor视角简化此模型。只需识别Actor可以执行的一小组有意义的交互（而不是低级别）。 例如：“上传照片”，“刷新数据”可能是一些固体UC
现在你需要一些“胶水”来联系不同的概念 - 每个用例使用组件图中的元素（+ couurse的actor）制作一个显示它如何工作的序列。
关键是“打开”用例并根据系统结构元素显示其内部实现。