服务器存储模块系统用例图,UML用例图服务器作为系统演员和其种用例

发送到应用程序的数据仅用于此智能手机/用户的此个人数据 。那么将服务器/数据库显示为 外部系统参与者与特定用途 个案相关联是否有意义？

只有当服务器/数据库是真的外部系统，到你的系统进行通信。如果不是，那么它不能成为一个参与者，并且你应该强制进行额外的UML建模来阐明整个系统结构(组件图+序列)。

数据是个人的事实与这个决定无关。 :)

在使用情况下(移动应用)，像奥得“刷新数据”，“关于 东西显示信息”有必要吗？因为我认为它们不是业务逻辑所必需的 。你怎么看？

如果您正在构建这个移动应用程序，并这些都是实现，应该比你definitelly捕捉它们作为用例的要求。

你是什么意思“他们不是必需的业务逻辑”？

首先，系统的范围是什么？ (移动应用程序，移动应用程序+服务器/数据库或其他)？

UPDATE(清理系统范围后)

我们正在构建的移动应用程序和数据库。所以我们不仅仅从 那里获取数据并发送数据。 We're建模整个 系统

范围现在已经很清楚 - databese /服务器不能是一个演员，因为它是范围的一部分。我看到的唯一演员是移动应用用户。

时只是将用户beeing演员和应用程序beeing的 系统我不知道怎么形容的使用情况，因为我相信我 必须在UCE案例说明该数据是发送至提到 服务器等...

你不必把所有的东西都放到用例描述中，我会很快回来。

例如：一个使用案例是关于拍照并发送这 的服务器 - -

那么，什么是这个UC问题？该角色是移动应用用户，用例是“上传图片”(可以选择包含拍摄照片)。

我觉得你很混淆了几个问题，你试图把所有的用例模型，这是不可能的。

所以，我建议你到cpncerns使(你的系统的各个方面)，下图中分离：

业务水平：显示应用程序的总体使用/业务流程的活动图

一个用例模型捕捉请求数

务必使这种模式简单，从演员个人pective。只需确定Actor可以执行的一小部分有意义的交互(而不是低级别)。 例如：“上传图片”，“刷新数据”可能是一些固体UCS

(可选)概念/数据模型经由(清理相关的数据结构)

系统结构组件/部署图(在这里，您显然至少有3个组件：移动应用程序，WEB服务器(或任何接收来自移动应用程序的请求)和数据库

通信机制 - 使用组件的序列图

现在，您需要一些“胶水”来关联不同的概念 - 对于每个用例，使用组件图中的元素(+ couurse的actor)来显示它的工作原理。

重点是“打开”用例，并根据系统结构元素显示其内部实现。