这一篇來告诉一个不容易分辨的关系图式：Association(结合)的各种類型，除了了解它的涵义 外，也让各位可以看图說故事，知道它背后所要表达的意义。 Association结合 Association是用來表达類别彼此之间的关系，这样的关系有很多个涵意，不管是实质上或 是概念上，也就是资讯是否有在兩个類别之间传递。 在PowerDesigner图示上，association是 包含在兩个類别间的线条，然后根据不同的属性关系，再以不同的图示來表达。 我们必须使用图 示看懂association所表达的关系，这样才能强化讀取類别图的速度和意义。
Navigable导览知识服务平台淘知音
假设这里有類别A和類别B，使用PowerDesigner设计association，从類别A拖曳到類 别B，预设的图示就是表达類别A具备讀取或呼叫類别B的能力，用较技术上的說明，就是類 别A具备類别B的類别变數，藉由这个变數去呼叫類别B的函數或是讀取類别B的属性值。 同 时在图示上，你会看到一个箭头在association上，其箭头方向和位置是在類别B的端点，如图 一所示。 在图一的范例，分别有订单主档和订单明细兩个類别，是使用association图示从類别 A拖曳到類别B的结果。 由于订单主档可能会讀取内含的订单明细资料，所以从類别A拖曳到 類别B，也刚好是预设的图示结果。
我们可以针对图一修正更精准一些。 订单主档会讀取订单明细，这是一种navigable(一般 称之为导览)的结果，是一种具备方向性的association图示；反之，假如订单明细需要知道所隸 属的订单主档资料，那由订单明细也要有一个navigable的association，指向订单主档。 要设计 这样的association属性，各位只要开启association的属性视窗，切换到Detail页面，在订单主 档下的Navigable属性，点选使其enable即可。 如图二所示。 各位应该会发现，association的图示，原本订单明细的navigable已经enable，同时有箭头指向订单明细，之后在你设定订单主 档的navigable后，由于双方都互有navigable，最后反而兩端都没有箭头了。
Multiplicity多重性
在图二中，各位应该也会看到Multiplicity这个属性，这是一种數量上的关系，表示引用对 方实例(instance)的數目。 就以这个范例來看，订单主档会引用多个订单明细资料，从最少一个 到多个明细，所以在订单明细上的Multiplicity设定就是1..*；反之，每一个订单明细只会指向一 个订单主档，所以订单主档的Multiplicity，就是1..1，表示最少一个，最多也是一个订单主档。 最后的结果应会如图三所示。
Aggregation聚合和Composition组合 接下來，我们再明确的表达更紧密的关系，也就是aggregation或是composition。 要說明 这样的关系，一定会有一个包含者和被包含者的关聯。 包含者会因需要引用被包含者的资料，包 含者是主动，被包含者是被动。 我们以前述的范例來說，订单主档就是包含者，订单明细就是被 包含者。 接下來解释aggregation和composition。 Aggregation是表示兩个独立的類别，彼此在不 同的領域各自运作，因为需要，彼此在一起工作。 至于composition，则是一种紧密的结合关系， 被包含者无法独立存在，必须有包含者存在；假如包含者消失，则被包含者一定跟着消失，这样 的关系下，被包含者是和包含者同生死。 以前例來說，由于订单明细在没有订单主档存在的情况 下不可能存在，所以订单主档和订单明细就是一种composition的关系。 我们可以开启 association的属性视窗，就在General页面，可以设定这样的关系组合，以订单主档和订单明 细來說，其设定的关系就如图四所示。
最终的图示，应该会如图五所示： 图五：Composition Association
至於 aggregation，我們舉一個例子來說明。例如車輛和輪胎的關係，車輛是包含者，輪胎
是被包含者，兩個結合起來，就可以提供駕駛的功能。可是萬一車輛報廢，則該輪胎可以離開車
輛，而與其他的車輛搭配來繼續使用，所以這樣的關係就是一種 aggregation 的關係。
結論
要清楚分辨 association 關係的各種屬性和圖示，就是這篇最重要表達的目的，尤其是
aggregation 和 composition，最容易為常人混淆。希望在這樣的解說之後，大家對於 Class diagram
所表示的 association 關係，就有正確的觀念以及有共同的解讀能力，這樣就能做到溝通的目的了。
