UML类关系

Question

UML类关系

3

我想确认一下当识别常见的UML类关系时，我是否正确。例如，以下关系属于哪种类型：

1. stackoverflow会员和他/她的stackoverflow用户账户之间的关系是组合关系还是聚合关系？起初，我认为这是一种关联关系，因为该成员“拥有”一个账户。然而，经过再次思考，我认为这是组合关系，因为每个“部分”（用户账户）只属于一个整体（用户）一次，也就是说，在我登录stackoverflow期间，我必须使用这个唯一的账户，直到我注销。如果我用另一个账户重新登录stackoverflow，则它再次变成组合关系。你同意吗？

2. 数据库和人的用户账户之间是聚合关系吗？我认为是，因为一个数据库（整体）可以存储0...*个用户账户（部分），但是另一个数据库可以存储相同的用户账户。

最后，有没有人能推荐一个专门用UML设计代码的网站？谢谢。

- Anthony

参见：http://accu.org/index.php/journals/551，http://ezinearticles.com/?Association,-Aggregation,-and-Composition---What-Are-They-and-How-Do-They-Differ?&id=1765256 - outis

@outis，我终于明白你的意思了。如果我理解正确，“stackoverflow用户账户”是代表“stackoverflow用户”的类，而真正的人无法被建模？我的理解正确吗？所以我只需要使用“用户”即可。 - Anthony

@01010011：类模型是对现实世界中的问题、系统或其他事物的一种建模方式。说真实的人无法被建模，就等于说真实的人无法用类来表示。我的观点是UML展示了类之间的关系，而不是现实世界和类之间的关系。 - outis

说用户和账户之间的关系是组合关系是无意义的，因为用户存在于现实世界中，而他们的账户存在于模型中。这就像试图测量爱荷华州得梅因市到地图上的位置的距离一样。一个人拥有一个账户，但这不是技术上的“拥有”关系。 - outis

@01010011：关于登录建模，你应该使用行为图而不是结构（类）图，因为“登录”是一个过程。你可能会使用活动图（http://en.wikipedia.org/wiki/Activity_diagram），它基本上是一个流程图，尽管身份验证可能会出现在用例图（http://en.wikipedia.org/wiki/Use_case_diagram）中用户和认证器之间的关系以及类图中（因为用户帐户和认证器之间必须有一些连接）。 - outis

显示剩余3条评论

6个回答

3

UML规范在聚合和组合定义方面存在不一致性。正如多位作者（包括Henderson-Sellers）所指出的那样，它们没有得到适当的定义。我建议您不要浪费时间去确定您的思维导图最适合哪种关系类型。没有正确答案。 :-)

就我个人而言，我经常使用抽象的整体/部分关系来模拟整体和部分。关于绑定、生命周期和排他性的语义可以通过伪代码或注释来给出。有这么多不同的情况和场景，试图事先预见所有可能性是不值得的。编辑：几年前，在UML早期版本的审核轮次中，Henderson-Sellers和我向OMG提出了这种方法。不幸的是，它没有被采纳。 :-)

即使UML是一致的，也没有正确或错误的模型；一些模型是有用的，一些则不是。您可以根据追求的目的创建模型。

- CesarGon

感谢您的回复CesarGon。是的，我确实在一本UML书中读到过，不应该为使用聚合还是组合而烦恼 - 书中只是建议默认使用聚合，并在以后进行更改，我忘记了这一点。整个设计编码之前的过程对我来说真的很新颖。不过，有一件事，您所说的抽象整体/部分关系是什么意思？您是指创建一个抽象类，然后让专门的类从中继承吗？还是更多的东西？我在谷歌上搜索了一下，但没有找到清晰的定义。再次感谢 - Anthony

1

比那简单多了。我的意思是只需使用“白色菱形”表示“整体/部分关系”，而不必关心它是聚合还是组合。毕竟，在UML中，“聚合”和“组合”是毫无意义的胡言乱语。它们缺乏明确的定义，一旦你试图规范它们的含义，就会发现严重的不一致性。因此，坚持使用更简单的东西，比如“整体/部分”，足以捕捉到你周围大多数情况的语义。正如我所说，你可以在必要时用注释来补充额外的细节。 - CesarGon

好的，非常感谢。还有一件事，你知道有没有专注于设计代码或网站的网站，供那些喜欢查看精美设计代码或代码设计的人使用吗？如果我能阅读比我更有经验的人编写的代码，我想这会对我很有帮助。 - Anthony

2

不，我没有。抱歉。通常情况下，书籍和网站中的图表很糟糕（例如，接受答案提供的图表是错误的；请参见我的评论）。UML 在其符号学和文件方式上都不太用户友好，人们往往会经常使用它不正确。抱歉我在这里无法帮助您。无论如何，我强调我在答案中所提出的观点：不要浪费时间寻找正确的模型；它们不存在。有些模型有用，而有些则没有。 - CesarGon

@CesarGon，有没有更精确的UML替代方案正在开发中？ - Anthony

有精确UML（pUML）小组（http://www.cs.york.ac.uk/puml）和由Steve Mellor和其他人完成的可执行UML工作（http://en.wikipedia.org/wiki/Executable_UML）。正如您所想象的那样，两者都基于UML。 - CesarGon

2

最好的UML书籍是Martin Fowler的“UML Distilled”。它已经出到第三版，所以它经受住了时间的考验。它具有罕见的优点，既包含了很多好信息，又非常薄。它对聚合与关联有很好的讨论。

Martin Fowler还提出了一些有关不同UML阵营的思考：MDA和“草图派”。我坚定地站在草图派的阵营中：不要过于强调将UML视为工程制图。它只是一个沟通设备，仅此而已。

- duffymo

1

仍然，它并没有解释聚合和组合。 :-) - CesarGon

你是在说软件工程师应该与一个无法生成工程艺术品的工具进行沟通吗？ :-) - CesarGon

1

个人而言，我认为这并不重要。重要的是级联删除行为：当父项有一个子项，并且您消除了父项时，子项是否独立存在或消失？Fowler的书在解释这一点方面做得非常好；他不同意您的措辞选择。在我看来，它一直是继承与组合，关联或聚合作为组合的子类型。继承意味着IS-A，组合意味着HAS-A。我从未在任何地方将其阅读为继承与关联。 - duffymo

1

老实说，我认为UML不值得花费那么多精力。在白板上画出盒子和箭头已经足够了。我与之合作的人并不真的关心元模型的细微差别。 - duffymo

2

你不必在每个注释结尾处都加上笑脸。 - duffymo

显示剩余14条评论

1

聚合：弱“拥有一个”
组合：强“拥有一个”

- kiwicptn

是的，还有聚合:“拥有一个”和“一个部分可能属于多个整体”。组合：“是一个部分”，“每个部分一次只属于一个整体，当整体被销毁时，部分也被销毁”。 - Anthony

1

我用来记住这两者区别的惯例是，组合关系意味着包含的实例不能存在于其封闭类型之外，而在聚合关系中，对象可以存在于封闭类型之外。

例如：

一辆汽车“拥有”4个轮子（聚合）
一辆汽车的车辆识别号码是汽车的“一部分”（组成）

（垃圾示例，但这是我能想到的最好的例子：）

- Paul Jenkins

看起来你把组合和聚合搞反了。当一个复合对象被丢弃时，它的部分也会被丢弃（但请参考CesarGon和duffymo之间的对话）。 - outis

感谢您的回复，Paul Jenkins。我对此还不是很了解，但我认为“拥有”关系指的是聚合；“拥有”关系指的是组合；“是...的一部分”关系指的是组成？换句话说：聚合=信用卡（聚合）PIN码（一部分），PIN码可以在借记卡和其他ATM卡中重复使用；组合=当整体被摧毁时，部分也会被摧毁。 - Anthony

"...我用来记忆的惯例..." 但显然不是很好。抱歉，当时已经很晚了。编辑后进行了更正，感谢指出错误 :-) - Paul Jenkins

0

这些额外的信息只能在UML中获得，因为你无法通过Java代码看到聚合和组合之间的区别。因此，我不同意聚合与组合不是一个好主意，因为这些信息对于项目质量非常重要！！

- UML GURU

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Arthur Ronald · Accepted Answer

一个stackoverflow成员和他/她的stackoverflow用户账户之间的关系是组合关系还是聚合关系？

好的，让我们看一下以下图表

聚合：

移植是可能的 如果我失去了一些手指，那么其他手可以接收到我的缺失手指

组合：

移植是不可能的 如果我失去了一些手指，那么没有其他手可以接收到我的缺失手指

聚合和组合都是如此，一个手指（部分）的生命周期与其所属实体实例的生命周期绑定（如果我失去了我的手，那么它的手指就会丢失）。因此，如果我删除我的Stackoverflow成员，它的UserAccount也将被删除。

回到你的问题：你的UserAccount虽然与其Stackoverflow成员的生命周期绑定，但如果丢失，可以被分配给另一个Stackoverflow成员吗？我认为不行。因此，这是组合。