问包含的/扩展的用例可以由另一个参与者发起吗？

EN

我会用这样的方式来建模：

​

​

Manager和Receptionist在这个上下文中具有相同的角色，这就是我使用泛化的原因。在不知道域名的情况下，这似乎没问题，但这只是一个提议。

<<extend>>受到{not allowed for actor Tech}的约束，{not allowed for actor Tech}显然不允许这个参与者进入这个(可选的)用例。

没有必要也将Receptionist与Update...关联起来，因为它是View...的扩展，但您希望能够首先不使用Viewing来实现Update。

关于<<include>>/<<extend>>的说明:它们并不意味着链接用例。UML规范声明(第638页)：

当有一些附加的行为需要添加(可能是有条件的)到一个或多个UseCases中定义的行为时，就可以使用扩展。

和

当存在两个或多个UseCases行为的公共部分时，将使用包含关系。然后将此公共部分提取到单独的UseCase中，由具有此部分的所有基本UseCases包含。

现在<<include>>看起来就像个混蛋。用例是关于唯一的附加价值的。如果在不止一个用例中存在行为复发，这种独特性就会受到质疑。在任何情况下，这些关系通常被看作是函数分解。这完全是错误的。从我的POV中，UML规范如果没有这些关系会更好。

在上述图表的上下文中，它表示一种模式，在这种模式中，您可以查看某些内容，然后才能使其可编辑。在没有<<extend>>的情况下，最好有两个单独的气泡，在Update中设置一个约束，告诉{ can only be reached after View... }。

既不应该包含，也不应该扩展。

视图工作类型和比率，和编辑工作类型和比率是完全有效的独立用例。

一般来说，将用例链在一起是个坏主意，因为您通常会一个接一个地做。您不应该尝试用用例来建模活动的顺序。使用您的业务流程分析。

您可以使用后置和先决条件来约束用例的执行。事实上，您的编辑用例实际上并不需要执行视图用例，对吗？它可能只需要选择一个工作类型。因此，它可以在任何具有后条件的用例之后立即执行，该用例说明所选择的工作类型。

哪个用例与编辑用例无关，只要在用例开始之前选择了工作类型。可能有10种不同的用例导致工作类型被选择。

我认为扩展是完全错误的。扩展用例通常是不完整的用例，将它们的行为插入到完整用例中是扩展用例中定义的特定扩展点。扩展用例中没有任何关于扩展用例的知识，也不需要或使用此行为的结果。

我发现扩展用例要适用的几个案例是像监视用例这样的事情。例如，监视系统中打开的票证数量的用例，并在超过某个阈值时向管理员发送警报。

如果您仍然坚持将用例链接到一起，例如，如果您的确实是，那么您只能在执行视图工作类型和分级之后编辑。包括用例视图工作类型，并从用例编辑工作类型中对进行评级，并对进行评级，这可能是第一步。

这两种解决方案(单独的用例，或包含从编辑到视图)解决了您关于不同用户权利的问题，因为现在毫无疑问，谁可以做什么？

我会把它改得包括在内。要更新工作，您必须查看它。查看它是强制性的。

在您的关系图中，Manager和Receptionnist是等效的，使用此架构，您只能定义一个参与者。或者Manager从Receptionnist继承的模型。

为了避免错误，如果您这样做，您必须确保接待员和Manager也可以激活视图用例而不进行更新。否则，必须取消一些联系。