理解代码中的UML关联
这是我到目前为止对关联、聚合和组合的理解。
协会
public class Foo {
void Baz(Bar bar) {
}
};聚合
public class Foo {
private Bar bar;
Foo(Bar bar) {
this.bar = bar;
}
}作文
public class Foo {
private Bar bar = new Bar();
}我认为理解这些单词的意思是没有意义的，除非我不能用实际的代码来表示它。上面的代码取自一个SO答案(告诉我上面的代码是不是错的)。
我的问题就是这些。
1)在类图中显示聚合和组合是否重要
2)我使用了一个工具，可以将java的.class文件转换成类图。Class Visualizer，但是我无法让这个工具在类图中显示聚合或组合关系。是这个工具有问题，还是我不了解如何在代码中使用组合和聚合？当我使用上面的代码进行关联时，这个工具给了我一个“依赖”关系的表示。(虚线)
回答 3
Stack Overflow用户
发布于 2015-04-28 05:23:55
是的，您上面的代码是错误的，因为它没有显示关联/聚合/组合是如何编码的。实际上，您的第一个代码示例是一个纯粹的UML依赖，而不是一个关联。关联总是在引用属性的帮助下编码/实现的，比如您的属性bar，它引用了Bar类型的对象。因此，您的第二和第三个示例是对Foo和Bar之间的关联进行编码的情况。顺便说一句，统一建模语言将组合定义为一种特殊类型的聚合(具有exclusive parts)，并将聚合定义为一种具有部分-整体关系预期含义的特殊类型的关联。
请注意，虽然众所周知(不同形式的)关联是如何编码/实现的，并且这在许多应用程序开发框架中都得到了支持，例如，在那些基于Ruby on Rails的活动记录范例的框架中，但在对象关系映射框架Java Persistency Annotation (JPA)中，还不清楚聚合和组合是如何编码的。事实上，UML的聚合概念是如此之弱，以至于它在代码方面没有任何含义。而且组合的UML概念太弱，不能在编码中有用/有意义。只有当我们通过要求组合的各个部分不能从它们的组合中分离出来(这个要求被称为不可分离的部分)来加强它时，就像我的SO answer和我的(获奖) CodeProject article中所讨论的那样，我们在代码方面得到了两个特殊的含义：
在这种更强的组合形式中，我们在组件和它们的组合之间有一个生命周期依赖，这意味着只要组件的组合是destroyed.
- Components的，组件就应该被销毁。
- 可以相对于它们的组合来命名/标识。
因此，您的问题"1)在类图中显示聚合和组合重要吗？“是：
a)不，聚合在类图中显示并不重要/相关，只需将其显示为关联即可
b)只有当组合具有不可分离的部分时，它才是重要的/相关的建模/显示在类图中。
Stack Overflow用户
发布于 2015-04-27 19:14:36
UML与代码不在同一级别，因此代码和UML之间没有一对一的转换。
有许多方法可以将代码反向工程到UML模型中，还有更多的方法可以在代码中实现UML模型。
因此，您必须理解UML概念本身，然后才能考虑如何在代码中实现这种概念。
网上有很多关于UML的书籍和解释，但唯一真正的来源是UML specificiation。
基于这个规范，我写了一篇文章，试图找出不同类型的关联之间的(有时是微妙的)差异：UML Composition vs Aggregation vs Association
Stack Overflow用户
发布于 2015-04-27 18:07:20
是否显示组合/聚合取决于。您展示了聚合或组合的元素变成了一个部分，没有聚合/组合元素就不能生存。例如，在数据库中，您显示当您删除父项时，组合中的子项将被删除，这是一个重要的声明。在不同的层次上(例如，当讨论从数据库实体派生的对象时)，这可能变得不那么重要。最后，它取决于目标读者群体。离开聚合/组合只会减少你传达给读者的信息。
我不知道Class Visualizer，但大多数UML工具只是将您的示例解释为依赖项(如果有的话)。它告诉我们：“两者之间有某种关系--你自己去想吧”。或者，您可以在导入后编辑生成的模型并使其更正确。
https://stackoverflow.com/questions/29889796
复制相似问题
腾讯云开发者
