Uml 包含/扩展的用例是否可以由其他参与者发起？

您好，我希望接待员和经理能够查看工作类型和费率，并随后进行更新。但是，技术人员只能查看，不能更新。这个图表有效吗

我读到扩展用例是由发起基本用例的参与者发起的。我应该如何区分技术人员只能启动基本案例而不能启动扩展案例？我不应该把推广协会放在那里吗？包含的用例如何

---

抱歉，如果以前有人问过这个问题。

我会更改“扩展方式包括”。要更新工作，您必须查看它。必须查看它

在您的图中，Manager和Receptionnist是等效的，仅使用此模式，您只能定义一个参与者。或经理从Receptionnist继承的模型

为了避免错误，如果您这样做，您必须确保接待员和经理也可以在不进行更新的情况下激活视图用例。否则，必须删除某些关联。

我会这样建模：

经理

和

接待员

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

受

{not allowed for actor Tech}

的约束，该约束明确禁止该actor进入该（可选）用例

无需将

接待员

与

更新…

关联，因为它是

视图…

的扩展，除非您希望能够在不先查看

的情况下
更新

注意：关于
/
：它们并不意味着链接用例。UML规范说明（第638页）：

当有一些额外的行为应该被添加到一个或多个用例中定义的行为中时（可能是有条件的），可以使用Extend

及

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

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

在上图的上下文中，它代表了一种模式，您可以在其中查看某些内容，然后才能使其可编辑。最好有两个单独的气泡，而不使用
，在
Update
中放置一个约束，告诉
{只能在查看后到达…}
您既不应该«包含»也不应该«扩展»

查看工作类型和费率和编辑工作类型和费率是完全有效的独立用例

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

您可以使用post-and-prepositions来约束用例的执行。事实上，您的编辑用例实际上并不需要执行视图用例，是吗？。它可能只需要选择一种工作类型。因此，它可以在任何具有声明工作类型的后置条件的用例之后立即执行

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

我认为这是完全错误的。扩展用例通常是不完整的用例，将它们的行为插入到完整的用例中是扩展用例中定义的特定扩展点。中的扩展用例不了解扩展用例，也不需要或使用此行为的结果

我发现“扩展”用例适用的少数情况是监视用例。例如，监视系统中打开的票证数量并在超过某个阈值时向管理员发送警报的用例

如果您仍然坚持将用例链接在一起，例如，如果您真的意味着您只能在执行用例后编辑费率查看工作类型和费率，我会反过来做。包括用例从用例编辑工作类型和费率中查看工作类型和费率，这可能是第一步

这两种解决方案（单独的用例，或从编辑到查看的包含）都可以解决您关于不同用户权限的问题，因为现在毫无疑问谁可以做什么。
如果您更改extend by include yes。哈哈，图表只是实际模式的快照，以说明我的问题。接待员和经理在其他用例中有不同的角色。然而，图表是否充分/合法地说明只有经理和接待员才能更新？（尽管他们也必须先查看）。是的，他们可以在不更新的情况下查看。尽管如此，如果我只是删除两个用例之间的关联是否更好？您可以这样做，但是如果您删除要更新的include（假设您更改了extend by include），则不必强制查看。如果您想更新它，您必须执行要查看的操作，您必须保留include。并考虑经理和接待员之间的继承关系：您的模式将更易于阅读。@granier也许您应该澄清一下，您的意思是否包括来自