我正在为一个新系统制作用例图。我想知道什么时候应该将系统包括在用例图中作为一个参与者？
4个回答
28
如另一个答案所述，演员是与正在开发的系统交互的系统或角色。如果一个系统不属于正在开发的系统，并且直接与正在开发的系统进行交互，那么你应该在用例中将其作为演员包含进来。
这很重要，因为你需要定义系统的边界，也就是它的范围和接口。将一个系统作为演员包含进来可以明确说明正在开发的系统需要为该演员系统提供合适的接口。
- Gabriel Ščerbák
2
系统的数据库是一个用例，例如存储数据，还是一个外部参与者，因为它接收输入或向系统提供输出？ - CommonSenseCode
通常情况下，数据库被认为是系统边界内的一部分，即它是与参与者交互而不是参与者本身的黑盒子的一部分。但也有例外。假设您设计了一个新系统，该系统连接到现有数据库并保持原样，则您可能会将该数据库视为参与者。但只有在相关利益相关者阅读您的用例时才这样做。 - www.admiraalit.nl
16
不同的人对于如何正确地使用UML进行建模有不同的哲学观点（这并不奇怪，因为UML是由委员会标准化的）。
我使用 "角色" 来捕捉每个可以与我设计的系统交互的 "事物" （人员类型、系统类型等），并发现它们有助于在所有利益相关者之间创建共同的理解，了解新系统的交互方式。
我建议为每个你知道将与系统交互的事物创建一个角色，并将该角色跟踪到角色可以执行的每个用例。这样，您就可以完全了解谁能做什么。
- Eric J.
7
在用例模型中，系统从不是一个执行者。您必须思考触发正在调查的系统执行过程的事物。系统本身是愚蠢的，不能自己触发行动。它只能由用户或时间触发。如果您认为系统正在触发操作，则可能是时间是执行者。例如，当接收到电子消息时触发运行流程，该流程完全自动化，不是由用户告诉系统消息已到达而触发的，那么谁是执行者？不是系统，而是时间。您需要想象的是，有一个处理程序来查找电子消息的到达，并以特定的时间间隔进行查找，例如每秒钟、每分钟或每月一次等。因此，在接收到电子消息时，是时间触发运行的流程。
- LNG
2
你专注于触发，而Gabriel Ščerbák专注于边界和范围。你们两个都提供了很好的指南。 - Alireza
3是的，确实如此。规范清楚地说明了这一点，您可以从OMG下载并检查。外部系统可以被描绘为用例图中的角色。UML 2.5 正式定义了一个没有参与者的用例是由其所包含的主体触发的（例如，一个预定作业）。 - Evandro Pomatti
0
《商业分析知识与技能框架》列出了几种可能的参与者类型，用于编写使用案例时从服务角度构建的原因（系统、事件触发器、服务）。例如，我的团队不拥有应用程序，也没有业务用户，我的测试人员将测试API服务，因此我需要从API角度描述我的用例，因此我需要说明API调用其他API时的行为。因此，一般有几种用例类型：业务用例，其中您说明应用程序中用户（人）的行为，系统/服务应用程序-其中服务调用其他服务以特定方式行事。根据业务分析师所在的团队，根据应用程序团队拥有或不拥有的情况，BA需要描述并采用适当的方法。
- user21782745
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接