问用例中的主要和次要参与者

EN

将主要演员放在左边和次要角色右边只是一种惯例，以便于熟悉该惯例的人阅读图表。这不是UML标准的一部分，所以您可以随心所欲地做。

就个人而言，如果它是一个UC的主要演员，我会把is放在左边，即使它是另一个UC的第二个演员，在相同的图表中。但是，把它放在另一边也是没有错的。

您需要从不同的角度来看待这个问题；根据您的描述，您正在制作支持库员工日常活动的软件(您正在为他们制作软件，以帮助他们完成工作)。因此，您不是在建模库本身，而是对库的业务域进行建模。主要参与者基本上是直接与该系统交互的人，以便在您正在建模的领域内执行业务功能--例如，系统可能使他们能够完成日常工作，或者他们正在使用该系统，因为它为他们提供了一些服务。

在第二个例子中，读者从不与系统交互(他们与图书管理员交互)，因此您可以合理地认为，在这个模型(和这个特定用例)的上下文中，读者根本不是参与者(而是在描述用例时可以提到的外部细节)。用例的含义不是“读者借用一本书”，而是类似这样的东西：“图书管理员进入借阅信息是为了让读者借阅图书，同时保持目录的最新更新”(请记住，系统的构建是为了满足图书馆的业务需求；另外，作为附带说明，我在这里使用了用户故事风格的描述角色-什么-为什么)。(当然，库可能有一个面向读者的门户，它是系统的一部分，但情况不同，用例也不同)。

所以我会把图书管理员当作主要的演员。在建模时，您必须决定模型的边界在哪里。例如，如果读者实际上是在为别人买这本书，那是别人发起的吗?以这种方式思考这个问题是否有帮助？基于您的问题，您隐式地设置了将整个库作为一个实体包括在内的边界，而不仅仅是您正在构建的系统；这可能感觉很自然，但从软件开发的角度来看，它并不一定有用。

关于次要演员的说明。当遵循任何实践或建议时，试着找出背后的原因--这并不总是容易做到的，但这是值得考虑的。那么，为什么我们首先要区分初级和二级角色呢？这个想法是为了找出系统存在的主要业务原因，以及它应该具备的主要功能，以满足为其构建的人们的需求，这样您就可以根据这些主要需求来构建系统。这是关于事物背后的“为什么”--不是出于哲学上的原因，而是为了在为某人建立一个系统时收集相关的信息。

用这种方式描述事物需要一些实践，但这很重要。使用同样的例子，图书管理员不希望访问特定的屏幕来输入有关一本书的数据(这缺少面向业务的“为什么”)；相反，图书馆员希望输入结帐信息，以便他们能够以一种有组织的方式提供图书馆提供的主要服务(让读者借阅书籍，跟踪书籍)。为了解决这些问题，您需要与在您的领域工作的人员以及将使用该系统的人(领域专家)进行交谈。了解这些，让我们做出正确的架构权衡(总是有权衡)，并提出一个初始架构，支持最重要的用户和最重要的功能。我说“初始”是因为当你在未来更多地了解这个领域时，当你注意到某些变化模式出现的时候，你可能仍然需要调整它。

次要参与者是支持参与者，从某种意义上说，它们是为了支持主要参与者的工作流程而存在的，但它们本身并不是业务价值的驱动因素。请注意，您不必事先想出所有这些。试着找出主要的参与者，然后在你进行过程中修改模型，因为这样做对你是有用的。在敏捷的环境中，你有很短的迭代时间，并且随着时间的推移，你可以学习、测试假设，并且随着你的理解的增长，对事情进行重新建模。

虽然克里斯多夫的回答很好，但是我和qwerty_so之间的评论让我找到了阿利斯泰尔·科伯恩的有效用例。尽管这本书的大部分内容使用了Cockburn所说的“盛装”的用例文档格式，但他也谈到了“随意”、“单列表”、“两列表”、"RUP样式“、”if-语句样式“、"Occam样式”、“图样式”(这不是UML用例图，而是序列、协作和活动图的使用)，以及UML用例图。

附录用于讨论UML用例图。在本附录中，准则之一是将“支持行为者放在右边”：

我发现把所有的主要演员放在系统框的左边，把右边留给辅助(次要)演员是很有帮助的。这减少了对主要角色和次要角色的混淆。有些人从来没有在他们的图表上画支持演员。这使它们能够将主要行为者置于双方。

因此，将主参与者放置在右侧，将次要参与者放置在左侧的想法并不是UML标准的一部分。即使在这本书出版时(2001年)，它似乎并不是一个标准。这只是科克本的风格，他甚至认为有些人甚至在他们的图表中不包括次要演员。

我还要指出，科克本对主要演员的定义与问题中提出的定义略有偏离。主要行动者是“要求系统交付其服务的利益相关者”，而主要行为者“在系统方面有一个目标”。这是“经常，但并非总是，触发用例的参与者”。

有两个问题：

• 谁是主要的演员？
• 用例图上的主要参与者在哪里？

我相信你可以证明，读者或图书管理员都是主要的演员。虽然在目前的系统实现中，图书管理员是与软件交互的人，但读者或图书馆的赞助人是要求系统提供服务的人。这是一个软件边界和系统边界的问题，以及调用系统交付其服务的确切含义。这是一件固执己见的事情--这里没有对错。

一旦你弄清楚了你的主要演员是谁，你需要决定你是否想让次要演员在图表上。最后，如果你要包括一个图表，它应该是可读的。增强可读性可能会导致您是否和如何在图表中部署参与者。从科伯恩的指导方针开始，可能会很有趣。

不过，如果我不提供关于UML用例图的另外两条信息，我就会失职了：

来自Cockburn的“编写有效用例”：

如果你花费大量的时间和精力担心图形和关系，你就把精力花在了错误的地方。

来自中的蒸馏器马丁·福勒：

在用例工作中，不要把太多的精力放在图上。相反，集中于用例的文本内容。

用例图是非常高级的，显示参与者、用例标题和关系。更详细的信息更有价值，根本无法在UML用例图中显示。如果你正在挑剔把演员放在图表中的位置，那么你就把精力花在了错误的地方。