10.5 從系統循序圖進入物件協作

10.5.1 SSD與物件層級循序圖

SSD把整體系統視為黑箱，適合確認參與者可以觀察到的系統事件。物件層級循序圖則把系統生命線分解為多個協作物件，用來探索哪些物件接收訊息、保存狀態及履行責任。兩者抽象層級不同，不應在同一張圖中一半採黑箱、一半展開內部元件。

10.5.2 從領域模型取得候選物件

物件層級循序圖可從既有的領域模型取得Registration、ProjectDocument及ReviewAssignment等候選領域物件；介面物件與協調物件則屬於逐步進入設計時的候選內容。每個新生命線都應說明來源與責任，不能只為了讓圖形看起來完整而加入控制器、服務或儲存庫。

10.5.3 物件協作圖

下圖示範如何把UC-03的整體系統生命線分解為候選物件。這是銜接分析與設計的教學示例，不代表介面與服務名稱已正式定案。

sequenceDiagram
  actor Captain as 隊長
  participant Page as 文件上傳介面
  participant Service as 文件上傳服務
  participant Registration as 報名
  participant Document as 專題文件
  Captain->>Page: 選擇報名並提交PDF文件
  Page->>Service: 要求上傳文件
  Service->>Registration: 確認報名可接受文件
  Registration-->>Service: 回覆確認結果
  Service->>Document: 建立專題文件紀錄
  Service-->>Page: 回覆上傳結果
  Page-->>Captain: 顯示處理結果

sequenceDiagram
  actor Captain as 隊長
  participant Page as 文件上傳介面
  participant Service as 文件上傳服務
  participant Registration as 報名
  participant Document as 專題文件
  Captain->>Page: 選擇報名並提交PDF文件
  Page->>Service: 要求上傳文件
  Service->>Registration: 確認報名可接受文件
  Registration-->>Service: 回覆確認結果
  Service->>Document: 建立專題文件紀錄
  Service-->>Page: 回覆上傳結果
  Page-->>Captain: 顯示處理結果

圖中的Registration與ProjectDocument可追溯至領域模型；「文件上傳介面」與「文件上傳服務」是候選設計物件。是否建立獨立服務、如何保存文件，以及報名在何種狀態下可接受文件，都必須在後續設計與需求確認中決定。

10.5.4 以責任檢查訊息配置

每個訊息都應由能履行該責任的接收者處理。若一個介面物件同時驗證規則、保存資料並決定業務狀態，可能代表責任過度集中；若領域物件只保存資料而完全沒有相關責任，也應重新檢查模型。互動圖的目的不是追求訊息數量，而是驗證協作是否合理。