UML 用例图中是否存在泛化？答案

【问题标题】：Does generalization exist in UML Use Case Diagrams?UML 用例图中是否存在泛化？
【发布时间】：2014-08-26 05:29:19
【问题描述】：

我正在尝试对一些需求进行建模，并且我在网络上看到了一些具有用例概括的示例，但是 UML 2.5 standard review 没有说明用例图中的概括，或者我找不到。

那么，标准是否支持泛化？

【问题讨论】：

你会如何——正式地——定义泛化。在我看来这很难。你几乎可以概括任何东西，直到没有什么好说的了......关于矩形是正方形的概括还是相反的问题有很多讨论（在数学中，这种关系很清楚，在 oo-design 中，它是肯定不是）。
@CommuSoft：为什么在OO设计中不应该明确Square是Rectangle的子类型？当然，可以正式定义特定类别类型的泛化。例如，OWL 这样做是为了类（对象类型）之间的泛化。
@gwag：因为一个简单的原因，一个矩形有一个额外的字段（和属性），这是违反 oo 设计的。我也会投票给 Square extends Rectangle`news.ycombinator.com/item?id=822354
@CommuSoft：就通用 OO 而言，您有一个观点，但问题是特定于 UML，其中确实正式定义了泛化。
@CommuSoft：这只是基于错误建模的误解。正确的模型是Square 是Rectangle( width, height) 的子类型，Square 附带一个不变量，要求宽度 = 高度。子类型化并不总是意味着添加属性，它也可能意味着添加约束/不变量（这在 XML Schema 中被 restriction 称为子类型化）。

【解决方案1】：

由于 UseCase 是一个分类器，它们可以被概括。 UML 2.5 规范在图 18.11 中包含了一个例子。 686（“ATM 服务”示例）。

【讨论】：

【解决方案2】：

棘手。

虽然泛化关系被定义为在两个分类器之间进行，而用例本身就是分类器的特化，泛化关系的语义主要集中在Features（例如Attributes）。这些是继承的，但关系不是。

另一方面，UML 规范本身包括一个用例泛化的示例（2.4.1 上层结构，图 16.7，p 609）。

首先，相同的规范省略了表 16.1“用例图中包含的图形节点”（第 611-613 页）中的概括，但确实包括了两个主要的用例内部关系；扩展和包含。

另一方面，同一张表包括 Actor，但不包括 Actor 和 Use Case 之间的 Association >.

可悲的是，UML 规范在许多方面都是一团糟，而 2.5 版本在一定程度上试图纠正这一点。

总的来说，我会说不 - 你不能在用例之间一概而论。

【讨论】：

对不起，我不同意。
我非常同意 :-) 2.5 绝对比以前的版本好。然而，很明显（对我来说）文档是由技术人员创建的，而 UC 部分应该由有时与客户打交道的人编写。 Bittner/Spence 是合适的顾问。
也许你应该说你不应该而不是你不能。

【解决方案3】：

我不知道官方 UML 标准是否“支持”用例泛化。但是

所以我的结论是，用例泛化得到了足够的支持，实际上你可以在需要时使用它。

但更常用的方式来表达一个用例是另一个用例的特殊化是（IMO）通过 > 关系。有关更详细的讨论，请参阅 http://www.uml-diagrams.org/use-case-extend.html 和 http://www.batimes.com/articles/use-case-goals-scenarios-and-flows.html（和 Wikipedia）

【讨论】：

好答案。我要补充一点，虽然 Sparx EA 是 IMO 最有用的建模工具，但它在执行 UML 标准的严格程度方面也是比较松懈的工具之一（这是它如此有用的原因之一）。因此，EA 做什么或不做什么并不能很好地表明标准所说的内容。
@Uffe 好点。我真的不知道标准到底是什么意思，实际上我并不太在意，我认为 OP 也不需要太在意，这就是我决定写一个答案的原因。我对“标准支持 XY 吗？”的松散翻译。是“XY 批准的方式吗？”。一个实际的例子，标准有点落后于批准的方式，但仍然是批准的方式是要走的路是 HTML5，它现在是一个推荐但没有批准的标准，但它是在一些 measurable limits 范围内得到批准的方式。 UML 标准看起来和我很像
为了记录，泛化/特化关系是 UML 规范的一部分。
扩展关系实际上与继承关系截然不同。例如，我的答案中图表中的专业不能替代扩展。可以肯定的是，扩展更为常见，但它们不是一回事。

【解决方案4】：

正如 gwag 所提到的，泛化/专业化确实包含在用例规范中。更重要的是，有很多情况下它是有用的。这是一个示例，来自this page：

【讨论】：

不，这只是技术人员的观点。是通过 MODBUS（不管是什么）还是 TCP/IP 发送消息是一个技术实现细节。
@qwerty_so 既然你不知道MODBUS是什么，你也不知道它是否只是一个技术实现细节。特别是（在查找了一些东西之后），导航器似乎通过两组离散的设备进行通信，这些设备使用这些协议中的一个或另一个。所以这两个用例最好命名为“通过 MODBUS 设备发送”和“通过 TCP/IP 设备发送”。（但这有点长。）因此，通过 MODBUS 设备进行通信的过程与通过 TCP/IP 设备进行通信的过程在技术意义上是不同的。
我查找了 MODBUS 并且（我的感觉证明是正确的）它只是另一个协议。因此，如所述的技术细节。抱歉，在涉及机组人员和导航员的层面上揭露这一点是疯狂的。导航器只是不关心鸽子或电缆用于发送消息的位置。他只在乎内容！他希望它看起来很安全。
@qwerty_so 一个合理的观点。这可能是一个不好的例子。但是，用例图中支持参与者和用例的泛化/专业化的基本观点仍然有效。
嗯，是的。 UML 允许它，但它没有真正的意义。引用一位前德国喜剧演员的话：没有哈巴狗的生活是可能的——但毫无意义。我会说：带有通用 UC 的 UML 是可能的——但毫无意义。我站在乌夫一边。