9.4 關聯、角色與多重性

9.4.1 關聯的意義

關聯表示兩個類別的實例之間具有連結。類別圖以實線連接相關類別，並可加入關聯名稱、角色名稱與多重性。

關聯名稱使用能被雙向閱讀的動詞或動詞片語。例如「團隊提交報名」，也就是報名表被團隊提出；「承辦人員指派評審」也就是「評審接受分派」。如果類別名稱與角色已足以表達語意，也可省略關聯名稱，但不應因省略而造成歧義。

9.4.2 角色名稱

角色名稱說明某一類別在特定關聯中的身分。同一類別可能扮演不同角色，例如學生在團隊中可能擔任隊長或一般隊員。角色不一定代表不同類別；是否需要將類別區分為子類別，應視其特徵與行為是否真正不同而定。

Case M01中的「競賽承辦人員」與「主辦單位」是不同的參與者角色，可能由不同人擔任，也可能由同一人擔任。領域模型不應因為角色可能由同一人兼任，就將兩種角色合併成同一概念。只要這兩個角色可能由不同人擔任，就需要分成不同角色。

9.4.3 多重性

多重性表示一端的一個實例，可以或必須連結另一端多少個實例。常用表示如下：

舉例來說，Case M01的BR-01規定每個參賽團隊由3～5名學生組成，因此靠近Student的一端可以標示3..5。但是，BR-01沒有規定一名學生可以加入幾個團隊，因此靠近Team的一端不應自行填入0..*。分析人員應先省略該端的多重性，建立待確認事項（To Be Confirmed，簡稱TBC）並向領域人員確認；若確認結果形成正式限制，再建立或修訂相應的業務規則。

BR-01規定的「每個參賽團隊由3～5名學生組成」，在實體關係圖（Entity Relationship Diagram，簡稱ERD）常用的鴉爪標記法中無法精確表示，但在類別圖中可以直接標示為多重性3..5。至於系統開發階段要如何落實這項數值限制，可以用參數的方式設定，或採取固定數值的方式處理；若主辦單位日後決定放寬或調整這項人數規定，屬於業務規則的變更，仍須先修訂BR-01並經過需求變更程序確認，不應由系統管理者逕自更改參數了事。

classDiagram
  class Team
  class Student
  Team -- "3..5" Student : 由學生組成團隊

classDiagram
  class Team
  class Student
  Team -- "3..5" Student : 由學生組成團隊

圖中的3..5具有BR-01支持；靠近Team的一端暫不標示多重性，表示目前尚無足夠資料可以定案。省略不是忽略問題，而是誠實揭露模型的知識邊界。若後續確認每名學生在同一競賽中最多只能加入一個團隊，便可在靠近Team的一端標示0..1，如下圖所示。

classDiagram
  class Team
  class Student
  Team "0..1" -- "3..5" Student : 由學生組成團隊

classDiagram
  class Team
  class Student
  Team "0..1" -- "3..5" Student : 由學生組成團隊

9.4.4 多重性的驗證

多重性應以具體問題向領域人員確認，例如Case M01就需要確認以下資訊：

• 一筆報名是否必須對應一個團隊？
• 如果系統內有多個競賽，一個團隊能否在不同競賽中各有一筆報名？
• 同一位指導教師最多可以指導幾個團隊？是否需要上限？
• 一個專題要指定多少個評審？
• 一份正式評分是否必須對應一項有效分派？

若資訊無法確認，應將問題列入待確認事項（TBC），而不是用看似完整的圖來掩蓋不確定性。以Case M01來說，BR-01只規定每個團隊由3～5名學生組成，不涉及指導教師的數量。其他關係若在後續獲得確認，應另以適當的業務規則記錄，不應擴張BR-01的範圍。待確認事項也不能直接被視為可調整參數；是否允許系統管理者修改、修改權限為何，以及變更後適用哪些資料，都必須先形成需求，才進入設計與實作。