和ChatGPT討論並生成草稿，再透過自己的理解修改。
此文章作為學習紀錄的用途。

將語意(Meaning)對應成物件模型

上一篇僅說明物件導向程式設計(Object-oriented programming)的元素的基本定義，而應用時通常是從語意對應，實作成所需的程式。

可以直接透過多種AI工具(對話式AI)完成將語意對應成物件模型的任務。

1. 語意(Meaning)

本文的語意(Meaning)是「語言所表達的意思(meaning)」。

1.1 語意(Meaning)和「業務語意」

語意(Meaning)

🎯 比喻

語意就像一封信的用意，雖然文字寫得清楚，理解卻需根據上下文、收信人背景、當時情境來決定真正的意思。

📘 說明

語意是一段語句的意圖、邏輯結構、作用的分析。
需求可以來自:

• 語言敘述(需求會談等)
• 分析及規劃文件(簡報摘要、規格草稿、企劃簡述)
• 規格文件(API文件、標準規範、合約模型)

業務語意

「業務語意」是公司裡對「業務概念」所形成的語言邏輯。就像各部門對訂單的認知，會有各自角色的解釋與關注點。
目的是透過「一致性的理解」，使「需求」依照預期的轉化為軟體。

建立一致的語意(Meaning)

在協作的環境中，需透過明確的機制「對齊」語意並達到「一致性」:

• 詞彙表:
  依照使用範圍，為名詞與術語紀錄定義，例如客戶、訂單、核准等，並作為參照標準。
  將一致的詞彙用在各個名稱，從需求到模型，以供辨識。

• 協作工具:
  使用互動式工具(如Figma、Miro、BPMN流程)進行跨部門驗證，讓參與人員都能直接操作模型，進行模擬與驗證，在模型中逐步對齊語意。

高階概念到低階概念的語意(Meaning)

1.2 語意對應到模型元素

將語意對應到模型元素並且對齊(雙向對應)。
對應到模型後要驗證雙向對應。

語意(Meaning)的分類與對應模型元素

範例:「使用者登入系統，若帳號已綁定Google則可快速登入，否則須先進行驗證。」

判斷類別(Class)、抽象類別(Abstract Class)、介面(Interface)

語意中的「實體」，可轉為類別(Class)、抽象類別(Abstract Class)。

判斷方法(Method)

語意中的「動作」、「描述動作」可轉為「方法」。
分析是否有:

• 動作的「主詞」: 類別(Class)/抽象類別(Abstract Class)/介面(Interface)。
• 動作及「條件」: 用在方法名稱、方法邏輯。
• 動作依賴或關聯的名詞，描述「條件的判斷點」、「產生結果」: 變數、參數、回傳值，可能是資料或類別(Class)。
  • 依賴或關聯的類別(Class)，使用UML關係。

判斷建構式(Constructor)

語意中若出現「建立」、「新的」、「產生」+「實體」，通常對應到建構式(Constructor)。

判斷屬性

屬性分為:

• 類別(Class): 實體，使用UML關係。
• 值: 資料，非實體。
• 集合: 包含多個實體或資料。

1.3 UML關係的語意判斷

在語意中，當主詞和受詞都是實體時，對應到UML關係。

判斷步驟範例

兩個實體具有「實例」關係:

1. 是否屬於「單向」的「使用」、「觸發」等「臨時關係」的語意？

   • 是 → 使用 依賴(Dependency): 語意為「使用(use)」。
   • 否 → 下一步。

2. 是否具備「部分-整體」、「組成」的語意？

   • 否 → 使用 關聯(Association): 維持一段時間的關係，生命週期彼此不影響，例如用在可為空值的屬性。
   • 是 →
     • 參照實體是否可被多個實體共用？
       • 是 → 使用 聚合(Aggregation): 語意為「有(has a)」。
       • 否 → 使用 組合(Composition): 語意為「是一部分(is a part of)」，子實體不單獨存在。

兩個實體具有「類別(Class)層次」關係:

• 是否為「是一種(is a)」的語意？

  • 是 → 使用 泛化(Generalization)。

• 其中一實體有「提供具體功能」、「實現」的語意？

  • 是 → 使用 實作(Realization)。

其他狀況:

1. 多種判斷同時符合

   • 是否存在潛在實體
     • 是 → 分離出不同實體並判斷其關係。
     • 否 → 根據語意判斷是否衝突，或是開會討論相關的內容。

2. 無法判斷或屬於模糊語意？

   • 先使用 關聯(Association)，後續迭代開發再做調整，否則開會討論。

是否有完全的優先順序判斷步驟? 有多種解答，可能簡單地從語意及相關定義判斷比較快，也可能參考既有模組使用適合的判斷步驟。另外還有既有的設計模式可以用。

UML關係與實體類型判斷

1.4 從語意(Meaning)概念層次區分工作流程

1. 概念層

• 來源: 使用者故事、訪談紀錄、需求討論紀錄。
• 輸入條件:
  • 語句中已出現明確實體與動作語意。
  • 談話或記錄中可標記出「誰做了什麼」。
• 輸出: 語意標記表: 語意實體，以及其動作、資料、限制條件。

2. 對齊及轉換層(分析和規劃)

• 來源: 語意分類表、詞彙表、臨時的紀錄文件、先前的設計。
• 輸入條件:
  • 語意實體可對應模型元素(如類別(Class)、屬性)。
  • 動作語意可轉換成方法、輸入/輸出資料、限制條件。
• 狀況:
  • 若有語意未對應元素，返回概念層進行修訂。
  • 若資料無法確定型別，使用通用類型(string)。
  • 既有模型的遷移對應設計及流程。
• 輸出: UML草稿圖。

3. 設計層

• 輸入條件:
  • 單獨範圍內的所有語意已分類(類別(Class)/屬性/方法/關係)。
• 輸出: UML文件或是相同作用的模型設計文件。

工具與文件說明