用例图 - 系统作为收集客户信息的Actor

Question

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

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

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

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

请指教，因为我找不到系统演员提到的很多例子。

Answer 1

通常不会让系统像演员一样（除非是外部系统）。

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

• 如果“个人信息”将直接从客户那里回忆，那就是演员。
• 如果该操作是由于其他操作而启动的，则必须使用<<include>>或<<extension>>点。
• 如果最终发生了动作，您可以创建“时间”角色。

Answer 2

从UML 2.5标准：

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

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

Actor只能与UseCases，Components和Classes有关联。 此外，这些关联必须是二进制的。

当您希望系统指向某个东西时，关联就是您的意思。 只要注意，用例的关联没有箭头 - 它们会过多，导航总是从Actor到Use Case。 所以，它并没有指向用例，而是与它相关联。

正如你所说，

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

所有这些都是用例，必须连接到演员“客户”。

如果子系统与某些用例一起使用，则子系统应显示为包含这些用例的大矩形，或者通过连接“包含”与这些用例连接的小矩形 - 在容器侧具有交叉圆。

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

如果要在此级别上显示部署，则服务器或客户端comp可能与用例关联，因为PC不是一组用例。 （但主要是在部署图上显示部署更好）

决定性地，产品数据库系统包含用例更新产品数据库。 它不是演员。

Answer 3

用例非常简单......但很多人混淆错过使用它们......

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

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

用例就客户语言而非编程术语而言。 它给了系统应该怎么做系统不会这样做。

和

它应该有一个主要的角色，通过执行用例获得好处或实现目标。 没有任何数据库可以从任何方面获益。

用例是非常高级别的功能要求。 他们回答了这些问题：

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

让我们回答你的问题：你有一个要求

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

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

许多要求不会以用例形式表达。 不要担心......对它没有错误。只需将它们记录在其他格式中。

而Use Case Diagrams比用例更受欢迎。 Unfortuanely。

事实上，您的补充要求会向我们介绍另一位演员。 由于谁将采取客户收集的数据...

假设您的客户决定使用非常复杂的数据挖掘工具，您的应用程序只需向该工具提供数据[集成到该工具]。 由于第三方软件超出了您的范围而您只是使用它，因此另一个系统可以成为您的第二级演员。

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

UML标准和演员类型 [再次那些无聊的标准:-)]

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

• 主要演员
• 男配角

主要参与者通过使用SuD的服务来实现用户目标。[正在讨论的系统]。为什么要识别？ 查找用户目标，从而驱动用例。

支持演员向SuD提供服务（例如，信息）。提供计算机系统，但可以是组织或个人。 为何识别？ 澄清外部接口和协议。

[来自Craig Larman，应用UML和appaterns] [实际上他确定了三种外部演员 - 第三名前台演员 - 但对我来说2种类型都很好]

这是来自RUP [Rational Unified Proccess]的术语，而不是来自IBM工具的术语。 演员之间的概括与演员类型不同。 要获得更多信息，请查看Larman的书“ Use Case Primer”中的免费章节