我开始学习UML了,我有点困惑。我有以下用例图:

我提出这个问题是因为我想正确地绘制我的图表,以便任何对UML有正确知识的人都能理解,而不仅仅是以我理解的方式绘制图表。
现在,由于我使用用例泛化的原因,这里是为什么;
在阅读了“UML2”一书第5.3节和统一过程之后,我认为我要做的是用例泛化,特别是在查看了第100页中的示例之后。此示例展示了一个名为FindProduct的用例,如第101页所述,该用例是一个抽象用例。
我们读到了
FindBook用例要具体得多。它专门研究更抽象的家长来处理特定类型的产品,书籍。如果父用例没有事件流或不完整的事件流,则它是一个抽象用例。抽象用例非常常见,因为您可以使用它们在最高抽象级别捕获行为。由于抽象用例缺少或不完整的事件流,因此系统永远无法执行它们。
这就是我试图在我的图表中表达的。我有一个抽象的用例,打开,这个用例永远不会按原样执行。它需要孩子,或者在这种情况下,孩子来专门化它,因为系统将通过IR或旋钮打开,而不是仅仅打开,这是抽象的。
所以这里的问题是,我不确定多重泛化,如果这样做是正确的。或者我是否应该改变例如,打开IR,转动旋钮,打开IR,打开已知的用例,并使这些的子程序打开E 220,并添加E 121用IRE 222和E 123和E 123用例关闭,并使这些E 125的子代关闭E 226等等?
谢谢!!
发布于 2013-02-15 02:24:34
关于您的问题:我见过的最常见的方法是每个用例都有一个活动图。
关于用例图的几个要点:
我从未见过用例图中的多个专门化。你应该重新考虑一下。当用例A(子)专门处理用例B(父)时,它继承了所有的先决条件、后置条件、主流和可选流程步骤。我可以猜到,对于父用例来说,这些特性是不一样的(例如,打开卷和打开);因此,至少可以说,多重专门化在这里是没有意义的。
2-应该避免用例泛化,除非它为模型增加了实际价值。这不是很直观,使你的图表模糊不清。
这个用例图似乎倾向于把用例看作类,把泛化看作继承;这是不正确的。
4-您可能也想重新考虑用例的粒度级别;打开IR/Knob,关闭IR/Knob,所有这些都可以集成在一个合理大小的用例中,并有一些可选的流程。但这是你作为需求工程师所做的一个选择,任何人都可以采取不同的做法。
我建议您看看UML 2与统一过程书的5.3节,它是关于用例泛化的。
建议:
让我们假设您希望为打开和关闭保留单独的用例,并专注于一个用例(打开):
1-如果使用IR打开的步骤与用旋钮打开完全不同,请将打开用例抽象起来,不要为其编写任何规范(文本)或绘制任何活动图。然后专门化两种用例,称为用旋钮打开和用IR打开,它们是具体的,有单独的规范和/或活动图。
2-如果使用IR打开的步骤几乎与用旋钮打开的步骤相同,用户选择IR或knob的步骤除外;您可以使用替代流。在这种情况下,您只能有一个带有一个规范和/或一个活动图的用例。
对其他三个用例也这样做。
https://stackoverflow.com/questions/14887147
复制相似问题