UML类图的关联、聚合和组合怎么选？用生命周期判断关系

UML类图里的关联、聚合和组合，区别不在连线“强不强”，而在你向团队承诺了哪些业务规则：两个对象只是需要建立联系，还是存在整体与部分；部分能否共享；整体被销毁时，仍归属于它的部分怎样处理。没有明确的所有权和生命周期要求时，先用普通关联，通常比随手加一个菱形更准确。

绘制时可以使用Boardmix UML建模工具，把关系旁的业务规则与类图放在一起评审。先写出“删除课程后章节怎样处理”这样的具体问题，再选符号，能避免图画得规范、团队理解却不一致。

用三个问题，决定这条线要不要加菱形

先看双方是不是整体与部分。如果只是“讲师讲授课程”“客户提交订单”，有业务联系就可以用关联；“关联”并不意味着联系不重要。其次，若确有整体与部分，确认部分是否有独立身份、是否可以在不同整体之间共享或转移。最后，明确整体销毁时的处理规则，而不是凭中文里的“有”“包含”作判断。

IBM的UML类图说明用菱形区分聚合与组合，并强调组合中部分不能同时属于多个组合整体。实际选择时还要写清本系统的对象含义：同样叫“章节”，它可能是课程专属的章节配置，也可能是被多门课程引用的公共内容，两者不能套用同一条删除规则。

空心菱形不是所有“部分能独立存在”场景的必选项。如果它没有比普通关联多传递清楚的业务信息，保留关联并标出角色名即可。选择较简单的符号，不会妨碍你把共享、排序或转移约束写完整。

同一套课程系统，三种关系为什么不同

下面以一套课程内容管理系统为例。先约定四条规则：一门课程有一名主讲师；专题可以收录多门课程，同一课程也可进入多个专题；章节是某门课程内的结构单元；课程可以先建为空草稿，再逐步添加章节。这些是示例中的建模前提，不是所有教学系统都必须遵守的规则。

多重性要从另一端读：讲师端写1，表示一门课程对应一名主讲师；课程端写0..*，表示一名讲师可以暂时没有课程，也可以讲授多门。若业务允许联合授课，就应改动讲师端数量，而不是把关联改成聚合来表达“更多讲师”。

课程端的实心菱形表示课程是整体，不能放到章节端。章节端允许0..*，是为了容纳空草稿；如果讨论的模型只包含已发布且至少有一章的课程，可以采用1..*，但需要把这一范围写在图上。数量规则与关系类型是两个不同决定。

用删除、归档和复用场景，检查组合是否成立

“删掉整体，部分跟着消失”只有在“删除”含义明确时才有帮助。课程下架、归档、隐藏，并不一定意味着课程对象被销毁。若课程和章节仍用于历史记录，图中的对象依然存在，不能仅凭页面不再显示课程就判断组合规则被破坏。

• 删除专题：专题对象消失，课程仍保留，其他专题的收录关系不受影响。若系统把课程一起删除，就违背了前面约定的收录语义。
• 归档课程：课程与章节保持原关系，只改变课程状态。不要把“归档”等同于生命周期终止。
• 销毁课程：仍归属于该课程的章节随之销毁。本例课程端为1，若需保留某个章节，应在销毁前把它原子地转交给另一门课程，不经过无主状态，也不能让它同时属于两门课程。如果业务允许章节先脱离课程再等待归属，应将课程端改为0..1，并明确这段状态的管理规则。
• 复制课程：如果新旧课程需要独立编辑章节，应创建新的章节对象，再复制内容。两个章节文字相同，不代表它们必须共用同一个对象身份。

组合也不要求整体和所有部分在同一个瞬间创建。课程可以先创建，后续再增加章节；关键在于章节加入组合后的所有权与生命周期约束。

如果新需求是“修改一次公共知识点，所有引用课程一起更新”，可以进一步拆分对象：课程组合“章节配置”，章节配置关联“公共内容”。章节配置保存本课程的顺序和展示设置，公共内容保存被复用的正文。销毁课程可以结束它的配置对象，同时保留仍被其他课程引用的公共内容。这样既保留课程内结构，又没有把共享内容误画成独占部分。

这些画法看似合理，却改变了模型含义

• 看到字段引用就画组合。一个类保存另一个对象的引用，只能说明存在实现上的联系，不能证明整体与部分及生命周期责任。应回到业务规则判断。
• 把数据库级联删除当作唯一证据。数据库约束是实现方案；如果业务要求保留对象，不能反过来用现有级联设置证明它应该被销毁。
• 把空心菱形当成“弱一点的实心菱形”。先说清哪些身份独立、哪些关系可共享。只写“关系松散”无法指导删除或复用操作。
• 用箭头代替所有权。导航方向回答能从哪个对象找到另一个对象，菱形回答哪端是整体。两者不能互相替代，也不能把菱形理解为继承箭头。
• 同一章节挂在两个实心菱形下。这与同一部分同时至多属于一个组合整体的约束冲突。若确需复用，检查你要共享的是章节对象本身，还是它引用的公共内容。

关系不应由代码中“new写在哪个方法里”单独决定。领域模型首先表达对象的业务身份；设计模型再说明如何实现创建、保存、解除关联和销毁。两个视角可以关联，但不能省掉中间的业务判断。

在Boardmix中，把类图变成一次可验证的关系评审

在画布左侧列出本例四条业务规则，中间放四个类及关系，右侧放删除专题、归档课程、销毁课程、复制课程四张场景卡。每讨论一条连线，就沿相应场景说明哪些对象仍存在、哪些关系改变；有分歧时修改规则或模型，避免只讨论菱形的颜色。

1. 先写对象身份。分别说明课程、章节、专题和讲师代表什么；对于可复用内容，决定是否另建独立类。
2. 标出整体端和数量。给课程—章节的课程端加实心菱形，专题—课程按约定使用空心菱形或普通关联；再填写两端多重性与角色。
3. 用具体实例走一遍。例如课程A含章节A1、A2，又被专题P和Q收录。移除P时，A、A1、A2仍存在，A与Q的收录关系保留；销毁A时，按章节所有权规则处理A1、A2，并清理收录关系。
4. 把未决定项留在关系旁。例如“章节是否允许转交”“归档后是否仍可被专题收录”。由业务与技术共同确认后再更新图，避免各自按不同假设开发。

需要补充类、属性和操作的整体绘制顺序，可以继续阅读UML类图绘制步骤。已经有类图时，最有价值的下一步是拿一个删除或复用场景走通：读者应能从图和注释判断对象会怎样变化。

打开Boardmix，整理类关系与生命周期场景