UML 建模實戰第三彈：用例描述、事務處理與逆向透視圖邏輯

需求收集是軟件工程基石，用例建模最常用。本文深入理論與詞彙，闡明用戶界面、系統界面與用例描述的關係，揭示為何用例不應包含 UI 邏輯，並引入「事務處理」與「逆向透視圖」核心概念。

一、 用例模型構成

• 用例圖：UML 標準化，可視化路標。
• 用例描述：無統一標準，主流遵循 Ivar Jacobson 體系——前置條件、後置條件、基本事件流（成功路徑）、替代/異常流（如逾期費繳納後續租借）。

二、 事務處理：用例的原子單元

事件流由一系列「事務處理」組成：**參與者發起 → 系統響應 → 系統等待下一觸發**。每個決策點（參與者必須決定或提供信息）劃分事務邊界。系統極少無啟動而運行（即使基於時間觸發）。

序列圖中的事務識別

從參與者到最近類/實例的消息為起點，順箭頭至另一參與者或流程結束返回原參與者，即一個事務。貸款提交用例含兩事務：① 申請人請求新申請 → 填寫提交；② 提交後 → 系統請求信用報告。

典型用例含 3~15 個事務。分析階段序列圖允許後續追加方案（即新事務）。

三、 互連系統建模與逆向透視圖

電話網絡是典型「系統的系統」。貸款提交系統與徵信系統協作處理請求。

• 貸款系統透視圖（圖 3）：事務 2 結束於向徵信系統參與者發送請求。
• 徵信系統透視圖（圖 4）：事務始於外部參與者請求報告，終於系統返回報告。

逆向透視圖邏輯

分析階段可合併為單系統視圖（圖 5）；設計階段因通訊機制複雜必須分離，用參與者互相代表對方系統。

核心洞見：**系統 A 的事務「系統部分」與系統 B 的事務「參與者部分」互為子集/映射**。即：貸款系統發送請求 ↔ 徵信系統接收請求；徵信系統返回報告 ↔ 貸款系統接收報告。這種「概念級反轉」形成系統間的**概念粘合**，天然定義出雙方接口契約。

四、 應用於用戶界面設計

用戶界面本質上是「參與者透視圖下用例描述的逆轉」。若先設計 UI 再寫用例，邏輯會顛倒：事務處理必須在應用前被逆轉。這就是標準強調「用例從參與者視角描述，不含 UI 邏輯」的根本原因。

若基於 UI 寫用例已行之有效，請繼續；若陷入混亂，請回歸「參與者視角 → 逆轉得 UI」的正向流程。