扩展用例

时间:2013-01-30 13:55:51

标签: uml

在用例图中,如果用例B扩展用例A,是否意味着仅与用例A ...相关联的actor也与用例B(间接)相关联?

我正在制作犯罪记录管理系统的用例图。监狱长和警察都有权通过不同的输入搜索罪犯,然后访问他的全部信息。在查看罪犯的信息时,管理者也可以选择修改罪犯,而警察则没有。

现在我已经将“搜索”和“访问信息”的用例设置为两个角色都可以访问的用例。 “访问信息”用例扩展了“搜索”用例。现在,如果我通过图中的“更新”用例扩展“访问信息”,是否意味着任何可以访问信息的人都可以更新?也就是说,我是否会错误地描述警察也可以更新犯罪分子的信息。

*我没有在警察演员和更新用例之间建立联系。我对此处的间接关联感到困惑......通过搜索和访问信息。

1 个答案:

答案 0 :(得分:1)

  
    

如果用例B扩展用例A,是否意味着仅与用例A ...相关联的actor也与用例B相关

  

不,它没有。在向现有用例添加附加步骤或选项方面,“扩展”关系可以被认为是“添加”。因此,如果一个actor与用例A相关联,它们可能会或可能不会与扩展用例“B”相关联。

您可能正在寻找用例之间的继承(泛化)。如果用例B继承自用例A,那么如果一个actor与用例A相关联,那么这个关系将由用例B继承。这个问题(虽然工具允许你绘制它)是用例继承的语义不是这个标准真的很明确,所以你需要自己明确地定义你的意思。

看看你的例子的具体情况,我认为你几乎就在那里。如果您创建一个扩展“访问信息”的用例“访问和更新信息”,那么只有监狱管理员应该有权访问它。

您还可以考虑演员之间的继承,这可以很好地工作。例如,您可以拥有一个访问搜索和访问信息的基本角色“只读用户”。然后添加扩展“只读用户”的演员“信息所有者”(例如),并添加对“访问和更新信息”用例的引用。您现在正在做的是根据用户在系统中而不是在域中扮演的角色来描述用户交互。这可能是有用的,也可能是沟通的障碍 - 这一切都取决于背景。

如果与最终用户的沟通很关键,我建议保持图表非常简单,不要使用任何这些复杂的关系。另一方面,如果使用该模型的人具有相当好的UML知识,则使用“extends”和actor继承可以增加模型的精度并避免重复。