第 9 章

9.9 Case M01領域類別模型實作

物件導向分析與領域建模

9.9.1 確認實作範圍與一致性基準

Case M01「專題競賽報名與審查系統」的整體模型涵蓋四個既有流程範圍：

流程範圍既有使用案例主要規則與需求
報名與文件上傳UC-01、UC-02、UC-03、UC-09、UC-10FR-05、FR-11、FR-13～FR-15、BR-01、BR-09、BR-13
評審分派UC-04、UC-09FR-12、FR-13、BR-05
評分與更正UC-05、UC-06、UC-09FR-08～FR-10、FR-13、FR-16、BR-11、BR-12、DR-06
結果確認與公告UC-07、UC-08、UC-09FR-13、FR-17、FR-18、BR-10

模型必須遵守已確認內容，不以類別圖重新定義流程。例如，BR-11規定正式送出後不得直接修改已送出的分數，模型因此區分評分與評分更正申請；BR-10規定結果須經主辦單位確認後才能公告，模型也不能將「確認」與「公告」合併成單一無狀態的動作。

9.9.2 建立核心類別

整體模型採用下列核心類別：

類別定義主要依據
競賽接受報名、進行評審並產生結果的競賽活動Case M01系統範圍
團隊由3～5名學生組成的參賽單位BR-01
學生參與團隊的學生BR-01
指導教師指導團隊並涉及利益衝突判斷的教師BR-05、FR-14
報名團隊參加特定競賽的申請紀錄UC-01、UC-02、FR-15
專題文件隊長上傳的PDF專題文件UC-03、FR-11、BR-13
評審接受分派並評定參賽專題的人員角色UC-04、UC-05
評審分派評審與特定報名之間的審查指派UC-04、FR-12、BR-05
評分評審針對被分派專題建立的評分與評語UC-05、FR-08、FR-16、BR-11
評分更正申請正式評分送出後提出的更正請求UC-06、FR-09、FR-10、BR-12、DR-06
競賽結果經彙整並等待確認或公告的結果紀錄UC-07、UC-08、BR-10

「隊長」先建為學生在特定團隊中的角色，不另建永久身分類別；「競賽承辦人員」與「主辦單位」則保留為責任角色。人員帳號、權限指派與外部身分驗證的詳細結構屬於後續設計議題，本模型只保留FR-13所要求的有效身分約束。

9.9.3 建立關聯與多重性

目前具有明確依據或可安全表達的核心關係包括：

  • 依據BR-01，一個團隊由3～5名學生組成。BR-01不涉及指導教師人數。
  • 一筆報名屬於一個競賽及一個團隊。
  • 一項評審分派連結一名評審與一筆報名。
  • 一份評分必須對應一項評審分派，避免對未被分派的專題進行評分。
  • 一項評分可有零筆或多筆更正申請，以保留再次申請的可能；若業務只允許一次，仍須另行確認。
  • 一筆競賽結果對應一筆報名，並由競賽層級的確認與公告程序進行管理。

下列問題尚未獲得足夠的需求支持，不在整體圖中強制定案：

  • 同一位指導教師最多可以指導幾個團隊？是否需要設定上限？
  • 同一學生在同一競賽中是否只能加入一個團隊？
  • 重複上傳專題文件時，採覆寫或保存多個版本？
  • 每筆報名應分派幾名評審？
  • 同一競賽是否允許同一評審多次分派到同一筆報名？

9.9.4 建立整體領域類別圖

下圖以已確認的需求為主。具有充分依據的多重性才直接標示；尚未確定的關聯端則省略多重性，並在待確認事項中說明，避免把0..*誤用成「目前不知道」。

text
classDiagram
  class Competition {
    CompetitionId: String
    Name: String
    RegistrationDeadline: DateTime
  }
  class Team {
    TeamId: String
    Name: String
  }
  class Person {
    PersonId: String
    Name: String
  }
  class Student
  class Advisor
  class Registration {
    RegistrationId: String
    SubmittedAt: DateTime
    Status: RegistrationStatus
  }
  class ProjectDocument {
    FileName: String
    Format: String
    SizeMB: Decimal
    UploadedAt: DateTime
  }
  class Reviewer
  class ReviewAssignment {
    AssignmentId: String
    AssignedAt: DateTime
    Status: AssignmentStatus
  }
  class Evaluation {
    EvaluationId: String
    Score: Decimal
    Comment: String
    Status: EvaluationStatus
    SubmittedAt: DateTime
  }
  class CorrectionRequest {
    RequestId: String
    Reason: String
    Status: CorrectionStatus
    RequestedAt: DateTime
    ProcessedBy: String
    ProcessedAt: DateTime
    PreviousContent: String
    NewContent: String
    Decision: String
  }
  class CompetitionResult {
    ResultId: String
    Status: ResultStatus
    ConfirmedAt: DateTime
    AnnouncedAt: DateTime
  }

  Competition "1" -- "0..*" Registration : 接受
  Person <|-- Student
  Person <|-- Advisor
  Person <|-- Reviewer
  Team "1" -- Registration : 提出
  Team -- "3..5" Student : 由學生組成
  Team -- Advisor : 接受指導
  Registration "1" -- ProjectDocument : 包含
  Registration "1" -- ReviewAssignment : 接受分派
  Reviewer "1" -- "0..*" ReviewAssignment : 接受任務
  ReviewAssignment "1" -- "0..1" Evaluation : 產生
  Evaluation "1" -- CorrectionRequest : 提出更正
  Registration "1" -- CompetitionResult : 產生
Mermaid 圖形預覽Mermaid 11.12
查看並複製 Mermaid 程式碼
mermaid
classDiagram
  class Competition {
    CompetitionId: String
    Name: String
    RegistrationDeadline: DateTime
  }
  class Team {
    TeamId: String
    Name: String
  }
  class Person {
    PersonId: String
    Name: String
  }
  class Student
  class Advisor
  class Registration {
    RegistrationId: String
    SubmittedAt: DateTime
    Status: RegistrationStatus
  }
  class ProjectDocument {
    FileName: String
    Format: String
    SizeMB: Decimal
    UploadedAt: DateTime
  }
  class Reviewer
  class ReviewAssignment {
    AssignmentId: String
    AssignedAt: DateTime
    Status: AssignmentStatus
  }
  class Evaluation {
    EvaluationId: String
    Score: Decimal
    Comment: String
    Status: EvaluationStatus
    SubmittedAt: DateTime
  }
  class CorrectionRequest {
    RequestId: String
    Reason: String
    Status: CorrectionStatus
    RequestedAt: DateTime
    ProcessedBy: String
    ProcessedAt: DateTime
    PreviousContent: String
    NewContent: String
    Decision: String
  }
  class CompetitionResult {
    ResultId: String
    Status: ResultStatus
    ConfirmedAt: DateTime
    AnnouncedAt: DateTime
  }

  Competition "1" -- "0..*" Registration : 接受
  Person <|-- Student
  Person <|-- Advisor
  Person <|-- Reviewer
  Team "1" -- Registration : 提出
  Team -- "3..5" Student : 由學生組成
  Team -- Advisor : 接受指導
  Registration "1" -- ProjectDocument : 包含
  Registration "1" -- ReviewAssignment : 接受分派
  Reviewer "1" -- "0..*" ReviewAssignment : 接受任務
  ReviewAssignment "1" -- "0..1" Evaluation : 產生
  Evaluation "1" -- CorrectionRequest : 提出更正
  Registration "1" -- CompetitionResult : 產生

圖中的「人員」是共同身分概念，「學生」「指導教師」與「評審」則是可能重疊的角色分類；同一人可以在不同情境擔任指導教師與評審。此一般化只表達候選領域結構，並不是BR-05的完整實作方式。真正的利益衝突檢查必須以共同人員身分，比較「被分派評審」與「該報名團隊的指導關係」，不得只依角色名稱判斷。

9.9.5 以既有流程驗證模型

整體模型可用四組既有流程進行情境檢核：

  1. 報名與文件上傳： 團隊對特定競賽提出報名；隊長代表團隊提交資料並上傳符合BR-13的專題文件。
  2. 評審分派： 競賽承辦人員建立評審分派前，系統依BR-05排除指導該團隊者。
  3. 評分與更正： 評審只能針對有效分派建立評分；正式送出後不得直接修改，只能提出評分更正申請，由經授權的競賽承辦人員處理。
  4. 結果確認與公告： 各報名產生競賽結果；主辦單位完成確認後，競賽承辦人員才能公告。

若類別圖無法支持其中任一情境，就必須補足模型；若類別圖加入流程未曾需要、需求也未曾確認的限制，則應移除或標為候選。

9.9.6 建立追蹤矩陣

模型元素需求或規則相關使用案例一致性說明
團隊—學生3..5BR-01UC-01正式提交前檢查團隊人數
報名—專題文件FR-11、BR-13UC-03文件必須為PDF且不超過20 MB
評審分派FR-12、BR-05UC-04排除本人所指導之學生團隊
評審分派—評分FR-16UC-05僅能評定被分派的參賽專題
評分狀態FR-08、BR-11UC-05區分草稿與正式送出
評分—更正申請FR-09、FR-10、BR-12、DR-06UC-06正式送出後經申請與授權程序更正
報名—競賽結果FR-17、FR-18、BR-10UC-07、UC-08先確認，後公告
受保護操作的身分約束FR-13UC-09受保護服務執行前完成驗證；身分資料結構尚待設計

9.9.7 模型審查結果與待確認事項

模型審查應得到下列結論：

  • 類別名稱沿用Case M01 的用語，並一致使用「專題」。
  • 評審分派、評分與評分更正申請彼此分離，符合FR-09、FR-10、BR-11及BR-12。
  • 結果確認與公告維持不同責任，符合FR-17、FR-18及BR-10。
  • 主辦單位與競賽承辦人員不會因可能由同一人擔任而合併。
  • 團隊人數採BR-01確認的3～5人。
  • BR-05已能透過團隊指導關係與評審分派進行檢查。

仍需交由領域人員確認的事項包括：

  • 團隊可有幾名指導教師，以及是否允許沒有指導教師？
  • 隊長的選任、更換與唯一性規則。
  • 專題文件的版本保存與替換規則。
  • 每筆報名所需的評審人數及重複分派限制。
  • 評分更正申請是否允許多次提出？
  • 競賽結果的排名、同分處理及公告內容。

這些問題在獲得正式決議前，不應透過類別圖自行定案。