用例图 - 系统作为收集客户信息的参与者

Question

我知道一个系统可以是一个参与者，它通常被绘制在系统边界的右侧。

我看到了一个示例系统用例 Actor 作为产品数据库系统，用例是更新产品数据库。

我有一个完整的问题，我被困在一段陈述“系统还应该收集客户信息，例如他们的个人信息、他们的购买偏好，例如价格范围等。

我不确定是否可以创建指向用例收集客户信息的 Actor？

请指教，因为我找不到很多关于 System Actors 的例子。

Answer 1

通常不会像演员那样拥有系统（除非是外部系统）。

参考那句话...取决于该信息的来源：

• 如果“个人信息”将直接从 Costumer 那里收集，那就是演员。
• 如果该操作是由其他操作启动的，您必须使用<<include>> 或<<extension>> 点。
• 如果动作最终发生，您可以创建“时间”actor。

Answer 2

来自 UML 2.5 标准：

Actor 指定由用户或任何其他系统扮演的角色 与主题互动。

所以，当然，一个系统可以是一个演员。但看起来，这个你的演员是主题的一部分？因此，将其显示为子系统。

Actor 只能与用例、组件和 上课。此外，这些关联必须是二进制的。

关联是您希望系统指向某物时所指的那条线。请注意，与用例的关联没有箭头——它们会过度，导航总是从参与者到用例。所以，它不是指向用例，而是连接到它。

如你所说，

系统还应收集客户信息，例如他们的 个人信息，他们的购买偏好，例如价格范围等。

所有这些都是用例，必须连接到参与者“客户”。

如果您的子系统适用于其中一些用例，则应显示为一个大矩形，包含这些用例，或一个小矩形，通过连接“包含”与这些用例连接 - 交叉圆圈位于容器侧。

内部系统和子系统不与用例相关联，它们以图形方式包含它们。您正在创建满足这些要求的系统 = 用例。它显示为遏制。系统由一组用例定义。从某种意义上说，就是那一套。

如果您要在此级别显示部署，则服务器或客户端组合可能与用例相关联，因为 PC 不是一组用例。 （但大多数情况下最好在部署图上显示部署）

当然，产品数据库系统包含用例更新产品数据库。它不是演员。

Answer 3

用例是如此简单...但是很多人混淆-错过使用它们...

“我看到了一个示例系统用例 Actor 作为产品数据库系统，它 用例是更新产品数据库”

上面用例描述的用例是错误的：

用例使用客户语言而不是编程术语。 它给出了系统应该做什么而不是系统如何做。

还有

它应该有一个主要参与者来获得好处或实现一个目标 通过执行用例。没有数据库可以从中受益 任何东西。

用例是非常高级的功能需求。他们回答问题：

我们为谁做这个系统？那些家伙可以用这个系统做什么？

让我们返回您的问题：您有一个要求

系统还应收集客户信息，例如他们的 个人信息，他们的购买偏好，例如价格范围等

这类要求称为补充要求。它们不适合用例定义。但它们可能与用例有关。

许多需求不会以用例的形式表达。不要担心...没有任何问题。只需以其他格式记录它们即可。

用例图比用例更受欢迎。不幸的是。

事实上，您的补充要求向我们介绍了另一位演员。既然谁来拿客户收集的数据...

假设您的客户决定使用非常复杂的数据挖掘工具，而您的应用程序只是向该工具提供数据[集成到该工具]。由于第三方软件超出了您的范围，而您只会使用它，那么另一个系统可以成为您的次要参与者。

甚至：假设您还将开发客户信息分析器系统，您可以将您的系统细分为在线商店模块和客户信息分析器模块 - 两部分 - 每个子模型将其他模块作为次要或主要参与者。

UML 标准和 Actor 类型 [又是那些无聊的标准 :-)]

许多人只使用用例图。所以他们的词汇只是基于 UML 用例图。用例中主要有两种类型的actor：

• 主要演员
• 配角

主要参与者通过使用 SuD.[讨论中的系统] .为什么要识别？找到驱动用例的用户目标。

配角向 SuD 提供服务（例如信息）。通常是计算机系统，但也可以是组织或个人。为什么要识别？阐明外部接口和协议。

[来自Craig Larman，应用UML和appaterns] [实际上他确定了三种外部演员-第三个舞台演员-，但对我来说两种都不错]

这是来自 RUP [ Rational Unified Process ] 而非 IBM 工具的术语。演员之间的泛化与演员类型不同。要获取更多信息 查看拉曼书中的免费章节Use Case Primer