我想确认我是否在正确的轨道上确定共同的UML类关系时。例如，之间的关系是：
1一个计算器构件和他/她的计算器的用户帐户归类为组合物的关系或聚合关系？起初我以为这是一个关联，因为该成员“具有”帐户。不过转念一想，我想它的成分，因为每一个“部分”（用户帐户）只属于一个整体（用户）的时间，这意味着，只要我登录到计算器，我都用这个唯一占直到我注销。如果我重新登录到计算器使用不同的帐户，然后它的成分一次。你同意吗？
2数据库和一个人的用户账号聚合关系？我是这么认为的，因为1个数据库（整个）可以存储0 ... *用户帐户（的部分），但另一个数据库可以存储相同的用户帐户数。
最后，任何人都可以推荐一个网站，使用UML专业设计的代码？提前致谢
甲计算器构件和他/她的计算器的用户帐户归类为组合物的关系或聚合关系？
好吧，让我们来看看下面的图
移植是可能的
如果我错过了一些手指，所以另一方面可以接受我的思念手指
移植是不可能的
如果我错过了一些手指，所以没有另一方面可以接受我的思念手指
这两种聚合和组合，用手指（的一部分）都有其生命周期绑定到其所属的实体实例（如果我错过了我的手，所以它的手指会被错过）所以，如果我删除我的＃1会员，其UserAccount将被删除。
回到你的问题：你的UserAccount，虽然有其生命周期绑定到其会员＃1，如果错过了，可以分配给其他会员＃1 ???我不这么认为。因此，它是组成
在UML规范与聚合与成分的定义是不连贯的。他们没有正确定义，如已被几个作者（其中包括恒基卖方）所示。我建议你不要浪费你的时间试图确定的东西在你的心中是否映射最好的一个或另一个。没有正确的答案。 :-)
我自己，我经常用一个抽象的整体/部分关系模型整体与部分。关于结合，寿命和排他性语义可以由伪代码或注释中给出。有这么多不同的情况和场景，试图事先预见到所有的可能性是不值得的。编辑：该方法的审查轮的UML的早期版本的前几年期间提出的亨德森 - 塞勒斯和自己OMG。不幸的是，它并没有做到这一点。 :-)
即使UML是一致的，也有不正确或错误的模型;一些模型是有用的，有些则不是。创建取决于你追求的目标模式。
对UML的最好的书是Martin Fowler的“UML精粹”。这是第三版，所以它经受住了时间的考验。它具有罕见的美德被挤满了良好的信息和剩余薄。
它聚集与协会商量好了。
Martin Fowler的也有关于不同的UML阵营的一些好的想法：MDA与“sketchers”。我坚定地在sketchers营：不要太挂了治疗UML，如果它产生的工程图纸。这是一个通信设备，仅此而已。
聚集：弱“的” 组成：强“有”
我用来记住哪个是哪个是一个复合关系意味着包含实例可以不存在没有它的封闭类型而在聚集体的关系，可以在不封闭类型作为一个例子存在的对象的约定：
（垃圾的例子，但最好我把我的头脑:)
因为你不能例如看到聚合和组合之间的Java代码的区别更多相关信息，只在UML用。因此，我不同意，聚集与组成不是一个好主意，因为这些信息对于工程质量的重要！