UML类图中Person类与Address类的关系判定及建模问题

第一个问题：Person与Address的聚合关系标记为association是否正确 #

先给结论：语法层面不算错，但语义没表达到位。
UML的关系层级里，*Association（关联）*是最上层的基础概念，所有描述两个类之间存在结构化引用的关系都属于关联，你说的Aggregation（聚合，共享Has-A）、Composition（组合，独占Has-A）都是加了「整体-部分」额外约束的特殊关联而已。
你既然已经明确判断二者是Has-A的聚合关系，只标普通association就等于把“谁拥有谁”的关键语义给丢了，应该在Person端加上聚合对应的空心菱形标记，把从属关系明确标出来。
顺便提一句，Person和Address也不是天生就该是聚合：如果你的模型里地址是每个人独有的内嵌属性，人删了对应的地址实例也跟着消失，那这关系其实是组合；如果地址是可以被多个人、多家公司共用的公共实体，人搬了家地址本身还存在，那才是你说的聚合。 #

第二个问题：类之间的关系类型是不是由建模需求决定 #

完全正确，从来没有脱离业务场景的“标准答案”，所有关系标记都是为你要表达的建模语义服务的。
你举的Book和Library的例子非常典型，两种标记方式都对，只是对应不同的建模场景：

• 要是你做的是单馆的馆藏管理系统，这里的Book指的是图书馆买进来的具体馆藏副本，从入藏到报废全生命周期都归属于这个图书馆，副本不可能脱离图书馆单独存在，那标组合（实心菱形在Library端）一点问题都没有。
• 要是你做的是跨馆检索平台，这里的Book是对应ISBN的抽象书籍条目，图书馆只是收录了这个条目的映射，图书馆下架书也不会把这个书籍条目删掉，同一本书还能被好几个图书馆同时收录，这时候就该标聚合（空心菱形在Library端）。

说句实在的，实际工作里很多团队都不会死抠聚合和组合的细微差别，甚至统一用普通关联代替，只要一起看模型的人对关系含义有共识就行，UML是沟通工具，不是要你死背规则的考试大纲。 #

内容的提问来源于stack exchange，提问作者back2back