雙階段分析架構
| 階段 | 論域分析 | 應用分析 |
| 目標 | 建立論域知識庫、理解業務本質 | 將論域知識映射至具體應用需求 |
| 範圍 | 廣泛、超出當前應用 | 受用戶需求限制、縮減資訊量 |
| 參與者 | 領域專家、分析師、架構師 | 產品經理、使用者代表、分析師 |
| 產出 | 論域模型:概念、關係、規則、約束 | 應用模型:具體類別、操作、介面、互動 |
| 表示方式 | 非特定程式語言 (UML/術語表) | 可對應程式語言 (類別骨架/介面簽章) |
| 邊界 | 模糊、持續演進 | 明確、由需求文件定義 |
論域分析:知識獲取與模型建構
核心活動
- 學習與探索:分析師深入業務現場、訪談專家、研讀法規/標準/文獻。
- 概念識別:物件、類別、方法、關係、規則、約束、術語。
- 模型整合:將識別概念整合為論域綜合視圖,資訊作為膠合劑連接相關概念。
- 關係明確化:概念間關係 (繼承/聚合/關聯/依賴) 必須在模型中顯性化。
團隊協作模式
- 小組包含領域專家 (業務知識) + 分析師 (建模技能)。
- 工作坊形式:事件風暴、領域故事講述、CRC 卡片。
- 產出論域術語表:統一團隊溝通語言,減少歧義。
論域模型價值
- 新成員快速上手業務知識。
- 需求變更時預測影響範圍 (廣泛論域知識 → 變更影響分析)。
- 多專案共享論域核心,避免重複建模。
- 支援產品線工程 (Product Line Engineering) 共性/變異點分析。
應用分析:需求篩選與模型實例化
核心機制:需求作為篩選器
用戶需求 → 篩選論域模型 → 保留相關子集 → 應用模型
- 論域分析視野越廣,應用分析保留彈性越大。
- 論域模型中未被當前應用使用的概念 → 保留於知識庫,備未來擴充。
模型識別兩大視圖
| 視圖 | 焦點 | 內容 |
| 應用視圖 | 使用者視角功能流程 | 用例圖、活動圖、介面草圖、業務流程 |
| 類別視圖 | 靜態結構與行為契約 | 類別圖 (屬性/操作/關係)、序列圖、狀態圖、介面規格 |
類別視圖詳細化要求
- 每個類別:完整屬性清單 (型別/可見性/限制/描述)。
- 每個操作:簽章、前置/後置條件、例外、演算法概述。
- 類別間互動:導航方向、多重度、角色名稱、協作序列圖。
從分析到設計的銜接
| 分析產出 | 設計轉換 | 設計產出 |
| 論域模型 | 細化 + 技術類別注入 | 設計模型 (領域層/應用層/基礎設施層) |
| 應用模型 | 具體化介面/演算法/資料結構 | 類別實作骨架、介面契約、資料庫 Schema |
實務建議
- 論域分析不設時限,持續累積知識庫 (Wiki/Confluence/模型工具)。
- 應用分析嚴格對齊需求基線,變更需求 → 觸發影響分析 → 更新模型。
- 模型工具支援版本控制 (Git 整合)、追溯矩陣 (需求↔類別↔測試)。
- 定期模型審查:領域專家確認論域模型、利害關係人確認應用模型。