9.1 從需求與流程進入物件導向分析
物件導向分析與領域建模
9.1.1 物件導向分析為什麼需要領域模型
需求規格可以說明系統應做什麼，使用案例可以呈現參與者希望完成的目標，活動圖可以描述工作如何進行，實體關係圖可以描述資料間的關係，但這些模型未必完整呈現業務資訊的結構。物件導向分析會進一步辨識具有獨立身分的物件、物件所保存的狀態、應承擔的業務責任，以及物件之間的協作關係。
例如，在Case M01中，「UC-04分派評審」說明競賽承辦人員要將參賽專題分派給評審，「BR-05規定評審不得審查本人所指導之學生團隊」。要判斷「UC-04的分派」是否符合「BR-05規則」，系統至少必須理解團隊、學生、指導教師、評審及分派之間的關係。領域模型正是物件導向分析用來整理這些概念與關係的重要工具。
領域模型將散布在文字和流程中的重要概念組織起來，使分析人員能夠檢查：
- 同一名詞是否在不同需求中具有相同意義？
- 一項功能需要的資訊是否已被辨識？
- 業務規則所涉及的類別與關係是否完整？
- 不同使用案例是否在操作同一個領域概念？
- 尚未確認的資料與關係是否被誤當成正式需求？
領域模型不追求呈現真實世界的所有細節，而是只呈現與目前系統範圍相關的概念與關係。
對Case M01而言，「學生」與「評審」具有重要業務意義，但與他們有關的所有事實並不都屬於系統範圍。例如，學生可能因修習某門課程而參加競賽，授課教師也可能同時擔任指導教師；然而，只要系統不需要處理修課原因與課程資料，就不應將這些概念納入模型。領域模型的品質不取決於內容多寡，而取決於模型是否保留了支援需求所需的概念，並排除與系統目的無關的細節。
9.1.2 問題領域與解決方案領域
進行物件導向分析時，必須區分問題領域與解決方案領域；本章的領域模型主要描述問題領域，而不是把兩者混合在同一模型中。
- 問題領域是系統必須理解與支援的業務世界，例如競賽、團隊、報名、評審分派及評分。
- 解決方案領域則涉及如何實作系統，例如前端元件、API、資料庫索引、雲端儲存及程式框架。
分析階段應先掌握問題領域，再逐步進入解決方案領域。如果模型在一開始就出現RegistrationController、UploadAPI或ScoreRepository，通常表示分析人員已過早採用程式設計觀點。這些元素未必錯誤，但不應取代「報名」「專題文件」或「評分」等業務概念。
9.1.3 領域模型與既有模型的關係
領域模型不是獨立創作的圖，而應以既有分析成果為依據：
- 從系統需求中取得業務名詞、業務規則、與資料限制。
- 從**使用案例中取得參與者的目標，以及系統必須處理的資訊。
- 從活動圖取得流程中被建立、讀取、更新或改變狀態的物件。
- 從驗收準則取得邊界條件、狀態與可驗證的約束。
- 從待確認事項辨識尚不能定案的類別、屬性或多重性。
例如，FR-11與BR-13支持建立「專題文件」概念，以及檔案格式、檔案大小等候選屬性；但需求若未說明是否保存每次上傳版本，就不能僅憑建模方便，而斷定一筆報名具有多個文件版本。需求沒確認的部分，必須加以確認。
9.1.4 領域模型的主要成果
一份可供審查的領域模型通常包含：
- 領域詞彙與類別定義。
- 類別的重要屬性及識別方式。
- 類別之間的關聯、角色與多重性。
- 需要使用關聯類別或一般化的結構。
- 模型元素所追溯的需求、規則或流程。
- 假設、限制及待確認事項。
圖形只是成果的一部分。若沒有文字定義與需求依據，同一張類別圖可能被不同讀者作出不同解釋。