9.7 從需求模型建立領域類別圖

9.7.1 確定模型範圍

建立類別圖前，應先說明類別圖要回答哪些問題。局部模型可以只分析UC-03「上傳專題文件」，整體模型則可能涵蓋報名、評審分派、評分更正及結果公告。範圍不同，所需類別和詳細度也不同。

模型標題或說明至少應記錄：

• 所涵蓋的需求或使用案例。
• 納入與排除的業務範圍。
• 模型版本與建模日期。
• 已確認的規則及待確認事項。

9.7.2 建立領域模型的步驟

可依下列程序建立領域類別圖：

1. 選定需求、使用案例或流程範圍。
2. 擷取人員、事件、交易、文件與紀錄等候選概念。
3. 合併同義詞，排除技術元件、動作與範圍外概念。
4. 為每個保留類別撰寫一句清楚的定義。
5. 加入理解需求所需的重要屬性與識別方式。
6. 建立具有業務意義的關聯，並為角色命名。
7. 依需求確認多重性，不確定者列為待確認事項。
8. 判斷是否需要關聯類別、組合或一般化。
9. 以基本流程、替代流程及例外流程檢核模型。
10. 建立需求追蹤，記錄假設並交由領域人員審查。

9.7.3 由UC-03建立局部模型

UC-03「上傳專題文件」涉及隊長、報名與專題文件。FR-11要求系統允許隊長上傳專題文件，BR-13規定文件必須採PDF格式且單一檔案不得超過20 MB。由此可得到：

• 「報名」與「專題文件」皆屬於候選類別。
• 專題文件至少需要包含檔案格式與檔案大小等資訊。
• 隊長是團隊成員在特定團隊中的角色，不宜直接等同於獨立人員類型。
• 是否保存歷次上傳版本尚未由FR-11或BR-13決定。

classDiagram
  class Team
  class Registration {
    RegistrationId: String
    Status: RegistrationStatus
  }
  class ProjectDocument {
    FileName: String
    Format: String
    SizeMB: Decimal
    UploadedAt: DateTime
  }
  Team "1" -- Registration : 提出
  Registration "1" -- "0..*" ProjectDocument : 上傳

classDiagram
  class Team
  class Registration {
    RegistrationId: String
    Status: RegistrationStatus
  }
  class ProjectDocument {
    FileName: String
    Format: String
    SizeMB: Decimal
    UploadedAt: DateTime
  }
  Team "1" -- Registration : 提出
  Registration "1" -- "0..*" ProjectDocument : 上傳

圖中的0..*僅表示「可能需要多次上傳保存」的候選設計，不能由既有需求直接證成。正式模型應在確認覆寫、版本保存及刪除規則後，再決定採0..1或0..*。

9.7.4 以使用情境檢核模型

檢核時可以選取一個具體情境，依流程逐步確認模型是否能提供所需資訊。例如：

1. 隊長登入並選擇某筆報名。
2. 隊長選擇PDF檔案。
3. 系統檢查格式與20 MB限制。
4. 系統保存文件及上傳結果。

若模型無法指出文件屬於哪一筆報名，就可能缺少關聯；若無法記錄格式與大小，就可能缺少屬性；若模型宣稱一筆報名只能有一份文件，卻沒有需求依據，就可能加入了過度限制。

9.7.5 建立可追溯性

每一個重要模型元素都應能說明其來源。追蹤表可以採下列形式：