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

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

来自UML 2.5标准：

  

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

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

  

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

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

正如你所说，

  

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

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

如果子系统与其中一些用例一起工作，则子系统应显示为一个大矩形，包含这些用例或一个小矩形，通过连接“包含”连接这些用例 - 在容器方面。

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

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

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

Answer 3

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

  

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

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

  

用例就客户语言而非编程术语而言。   它给出了什么，系统应该如何系统将这样做。

并且

  

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

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

  

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

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

  

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

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

  

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

用例图比用例更受欢迎。 Unfortuanely。

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

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

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

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

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

• 主要演员
• 支持演员

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

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

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

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

中的免费章节