Inheritance UML中继承的参与者具有不同行为的相同用例

我想对以下行为进行建模：当管理员创建一篇博客文章时，与用户创建一篇博客文章时不同，例如，版主在验证博客文章时参与创建博客文章用例。然而，当管理员没有管理员的角色时，他的博客文章也需要由版主验证，因为他自己继承了用户的行为

以下示例仅在管理员不想以管理员身份使用系统时，可以删除自己的角色时才有意义

我希望这是有道理的

尽可能简单 在同一个模型中，您不应该有两个相同的用例名称来表示不同的行为。这是非常令人困惑的

顺便说一句，UML规范没有定义当多个参与者与同一用例相关时的确切含义：可以是多个参与者，每个参与者分别参与用例的不同事件，但也可以是所有参与者每次都必须参与

因此，我建议保留一个与

用户

和

版主

相关的

创建博客帖子

用例。您仍然可以将

管理员

保持为

用户

的专门化，并在用例行为的详细描述中使用此专门化

但并非必要的简单 如果您认为这不能充分准确地表达您的情况，您有两种可能性

保持单个

Create blogpost

用例仅与更一般的

用户关联，并且
«extend»
它与另一个
适度blogpost
用例仅与
主持人关联。这是有意义的，因为调节用例是调节者自己的目标，它可以被重用（例如，也可以是
更新blogpost
的扩展）

由于参与者和用例都是分类器，您还可以想象一个用例

Create underated blogpost

是更通用的

Create blogpost

的特化。然而，这需要一些更精确的重新定义，在我看来，这并没有#1那么有表现力

第一种情况如下：

其他想法

---

主持人原则上也是
用户
。好奇：如果版主创建了一篇博文会发生什么：他/她能自我更新自己的内容吗？或者必须有一个四眼原则，确保有一个不同的现代人来主持这篇文章；-）
 回答太晚了，但这只是一个UC，其中您有不同的场景，受启动UC的演员类型的限制。@qwerty_所以，回答永远不会太晚；-）我见过这样的情况，即后来的答案比原来的答案获得多张赞成票。特别是对于一个有学习能力的人来说，最好把所有方面都展示出来，因此，如果你认为公认的答案是不够的，那么可以选择添加你自己的答案。@Ister没有机会与Christophe竞争。基本上他详细阐述了我的评论。和往常一样，长度最好。但是，是的，如果我有不同的意见，我也会在前几天回答；-）在我的IMO中，一个更好的选择是有两个不同的用例，但没有«扩展»。我可以想象，创建blogpost和调整blogpost是两个独立的活动，可以在完全不同的时间发生<代码>中度博客帖子

可能有一个前提条件，说明存在一个博客帖子草稿。我正要写与@Geert相同的东西。扩展意味着您在UC中有变体。但这是两个真正不同的UCs。嗯，我知道这是可以讨论的；-）但在任何情况下，我都会避免扩展，因为它们倾向于引入函数分解。@GeertBellekens确实，我同意。事实上，我开始意识到，在绘制第二张图表时，我的思维受到了原始UC的偏见（见我的橙色注释）。就我个人而言，我会将这两个UC完全解耦（即主持人每天主持一个等待博客帖子的队列，这是一个独立于博客帖子创建的目标）。尽管如此，我还是决定在便笺中保留提示，让OP选择如何最好地表达问题。@qwerty_所以我同意（更多细节请参见我对Geert的回答）谢谢你的回答。我同意，

适度的blogpost

应该是一个不同的用例。我只想在这个例子中说明，一个用例与另一个用例有一个稍微不同的过程-很抱歉造成混淆！