我正在根据以下场景创建用例图：
有一个移动应用程序，它将数据传递到Web服务器/数据库。另一方面，Web服务器将数据发送到移动应用程序。
所以我有两个问题：
发送到应用程序的数据仅是此智能手机/用户的个人数据。那么将服务器/数据库显示为与特定用例相关联的外部系统参与者是否有意义？
是否需要使用案例（针对移动应用程序），例如“显示有关某物的信息”或“刷新数据”？因为我认为它们对于业务逻辑不是必需的。你有什么感想？
感谢您的想法！
发送到应用程序的数据仅是此智能手机/用户的个人数据。那么将服务器/数据库显示为与特定用例相关联的外部系统参与者是否有意义？
仅当服务器/数据库确实是系统要与之通信的外部系统时。如果不是，那么它就不能成为参与者，您应该强制进行附加的UML建模以阐明总体系统结构（组件图+序列）。
数据是个体的事实与该决定无关。:)
是否需要使用案例（针对移动应用程序），例如“显示有关某物的信息”或“刷新数据”？因为我认为它们对于业务逻辑不是必需的。你有什么感想？
如果您正在构建此移动应用程序，并且这些是要实现的要求，则应明确将其捕获为用例。
您所说的“对于业务逻辑而言，它们不是必需的”是什么意思？
首先，您的系统范围是什么？（移动应用，移动应用+服务器/数据库或其他）？
UPDATE（清除系统范围后）
我们正在构建移动应用程序和数据库。因此，我们不仅仅是从那里获取数据并发送数据。我们正在对整个系统建模
范围现在很清楚-数据库/服务器不能是参与者，因为它是范围的一部分。我看到的唯一参与者是移动应用程序用户。
当仅将用户放置在演员和应用程序放置在系统上时，我不知道如何描述用例，因为我认为我必须在uce案例描述中提及数据已发送到服务器等。
您不必将所有内容都放在用例描述中，稍后我将再次讨论。
例如：一个用例是关于拍照并将其发送到服务器-
那么，这个UC有什么问题？参与者是移动应用程序用户，用例是“上传图片”（可以选择包括拍摄图片）。
我认为您对试图将所有问题都放在用例模型中的多种关注混合在一起感到困惑，这是不可能的。
因此，我建议您使用以下图表将cpncerns（系统方面）分开：
确保从Actor角度简化此模型。只需确定Actor可以执行的一小部分有意义的交互（而不是底层的交互）。例如：“上传照片”，“刷新数据”可能是一些可靠的UC
现在，您需要一些“胶水”来关联不同的概念-针对每个用例，使用组件图中的元素（+ couurse的actor），制作一个序列以显示其工作原理。
关键是要“打开”用例，并根据系统结构元素显示其内部实现。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句