<<use>>和<<composition >>同时需要吗？

Question

下面的UML包含类School (在我现在的示例中)只能有一个TeacherRoom。

我现在的问题是这个UML的官方符号是什么，或者我应该删除<> assosiation，因为它是显而易见的？很明显，因为我把TeacherRoom的一个实例保存在了学校实例中？

我会这样定义：

​

Answer 1

实际上，类teacherRoom : TeacherRoom中有属性School，这意味着School使用的是TeacherRoom，所以≪使用≫-依赖关系是不需要的。

您也有一个与TeacherRoom的组合关联。这意味着，除了属性之外，您还有第二个与TeacherRoom的关系。所以你可以移除任何一个。

Answer 2

根据我对UML2.5.1规范第10.4节的理解，使用依赖性说明了给定组件需要接口或服务这一事实。

所以我要删除它，因为这与“学校”是由"TeacherRoom“组成这一事实无关。

我的第二点是您的"teacherRoom“属性，它的含义与您的作文大致相同，因此我将删除其中的一个属性(属性或组合)。

Answer 3

因为你写了

只能有一个错误由我纠正TeacherRoom。

您需要在关联的右侧添加一个多重1 (删除菱形的注释和答复)。此外，与其在School中使用属性，还应该在关联中使用角色名teacherRoom，并通过添加一个点使其成为一个拥有的属性。

​

​

构图的一些附加注释:构图是(我个人的印象)，它会造成比实际更多的混乱，这有助于建立模型(只需寻找问题，询问它的语义和/或注意它的错误用法)。更糟糕的是，共享聚合导致(并导致)更多的混乱。现在，在许多版本之后，UML2.5将空洞的东西定义为它是什么:什么都没有。只需阅读第110页的方框即可。所以回到填充的一个，复合聚合。基本上是关于对象的生命周期，那么是否有一个对象的所有者负责它的生命周期。当你制造一辆由车轮组成的汽车时，这显然是不对的，因为车轮会在没有连接到汽车的情况下继续存在。只有这辆车不再是一辆车。但这将通过将4的多重性附加到车轮上来表示。任何没有四个轮子的汽车都不再是一辆汽车了。根本没有作文。

那么，在哪里可以使用复合聚合呢？我只考虑了两项申请。一种是存储管理。当像我这样的恐龙和拥有20兆字节的碗橱大小的硬盘并肩作战时，这一点在计算的早期是很重要的！只有少数边界情况仍然需要内存管理的指示。第二种情况是安全。表示必须与其父级一起删除某些内容。而且这仍然有效。但是，这是组合聚合的唯一真正应用。