[系統分析] MDA（Model-Driven Architecture）開發程序

[寫給SA的UML/MDA實務手冊 邱郁惠著] 筆記

個人與邱郁惠有數面之緣，發現她寫的書比講課要清楚明白，希望她以後能多多分享她的經驗，大家也要對她的著作多多捧場唷。

CIM-1定義企業流程（企業UC模式）的產出，有下列兩項：

1. 企業UC圖
2. 企業UC簡述

CIM-2分析企業流程，在於切分工作項目，其準則如下：

1. 依時間間隔切分工作項目
2. 純人工/可資訊化的工作項目，分開
3. 記錄系統上線之後的工作項目
4. 每項工作只有一位負責人（真正執行該項工作的員工）

CIM-3定義系統範圍的產出，有下列兩項：

1. 系統UC圖
2. 系統UC簡述

系統分析師在定義系統UC時，可參考下列建議：

• 每一個系統UC最好只有一個啟動者
• 系統UC執行期間如果有連線其他系統，將它們列為支援者
• 遇到定時啟動的系統UC，可以定義一個名為『定時啟動者(Timer)』的虛擬啟動者

系統分析師在繪製系統UC圖時，可以採用下列幾項常見做法：

• 採用帶箭頭關係線，讓啟動者連線指向UC，UC連線指向支援者。這樣一來，從圖面上就可以明確分辨出啟動者與支援者。
• 一個UC通常只有一個啟動者，不過可能出現多個支援者
• 如果有多個啟動者的情況，常是切割成一人一例(One User, One Session)
• 有時不同使用者都具有啟動UC的特性，建議在圖面上繪出最重要或最主要的啟動者，其餘啟動者紀錄在UC敘述裡，這樣可以降低圖面的複雜度

PIM-1：系統UC敘述

1. UC基本資料
   • UC名稱
   • UC編號(ID)
   • UC簡述
   • UC圖
   • 系統：提供此UC的系統名稱
   • 參與者
   • 相關UC：包含(Include)關係與擴充(Extend)關係。有相同流程時，使用包含關係；有可選擇性過程時，使用擴充關係。
2. 執行流程
   • 主要流程(Basic Flow)
   • 替代流程(Alternate Flows)
   • 例外流程(Exception Flows)
3. 要件及規則
   • 啟動事件或條件(Triggers)
   • 執行前要件(Preconditions)
   • 成功時要件(Postconditions on Success)
   • 失敗時狀態(Status on Failure)
   • 企業規則(Business Rule)
4. 相關文檔
   • UC敘述的歷史文本
   • UML圖
   • 參考畫面
   • 其他非UML文檔
5. 其他事項
   • 優先性(Priority)
   • 循環等級(Iteration)：替UC標示其細緻度或循環等級，方便開發人員經過多次循環的過程逐步定義出UC的細節。
   • 待解議題(Issues)
   • 基本假設(Assumptions)
   • 相關人員：將一個UC當成一個工作單元，加上相關人員的簽核之後，UC敘述文件就成了現成的工作單(Work Ticket)
   • 特殊需求(Special Requirements)

在進行PIM-1訪談時，針對每一個系統UC，系統分析師可以請企業人員協助回答下列問題，或者提供相關資料：

• 條列出企業人員現行的執行步驟
• 期望系統怎麼做，以改善現行作業的缺失
• 提供相關的紙本表單或電子表單
• 列出相關的企業規則和計算公式

PIM-2分析企業規則

企業規則：

• 目的：企業透過一組規則(Busses Rules)來控制整體的運作，包括人員、流程、系統、概念的運作，接受制於企業規則。
• 定義：企業領域中任何一項必須遵守的條件(Conditions)、限制(Constraints)或政策(Policies)都算是企業規則。

企業規則的分類：

• 限制規則(Constraint Rules)
  • 刺激/反應規則(Stimulus/Response Rules)：當某個重要的外界事件發生，而且物件如果恰好處於某種狀態下時，物件就會做出某種事先約定好的行為。
  • 操作規則(Operation Constraint Rules)：用來保證操作會正確執行。通常又分為操作前規則及操作後規則。
  • 結構規則(Structure Constraints Rules)：用來限制物件種類或結合關係必須永遠遵守規則。
• 衍生規則(Deruvation Rules)
  • 推論規則(Inference Rules)：指出某事實為真時，結局是可被推論得出。
  • 計算規則(Computation Rules)：就是一般所謂的計算公式。

PIM-3定義靜態結構

系統分析師可以透過檢覈下列兩項要件，判斷是否採用結合關係：

• 在企業領域的專業概念裡，兩種物件之間有一種固定不變且需要保存的靜態關係。
• 在資訊化時，系統會用到這些靜態關係，而且必須將它們存到資料庫。

系統分析師可以透過檢覈下列兩項要件，判斷是否採用一般化關係：

• 在企業領域的專業概念裡，特殊物件必須『是一種』(a kind of)一般物件。
• 多種特殊物件裡，有部分通用的屬性與操作，也又部分獨有的屬性與操作。

系統分析師可以透過檢覈下列四項要件，判斷採用結合關係、聚合關係還是組合關係：

1. 在企業領域的專業概念裡，兩種物件之間有一種固定不變且需要保存的靜態關係。(組合關係的要件)
2. 在資訊化時，系統會用到這些靜態關係，而且必須將它們存到資料庫。(組合關係的要件，符合上述要件1～2，即可採用結合關係)
3. 在企業領域的專業概念裡，兩種物件之間有Whole-Part的靜態關係。(聚合關係的要件，符合上述要件1～3，即可採用聚合關係)
4. Part物件只能連結一個Whole物件，且Whole物件被註銷(Destory)時，Part物件必須一塊被註銷。(組合關係的要件，符合上述要件1～4，即可採用組合關係)

PIM-4：定義操作及方法

在建構PIM-4的循序圖時，系統分析師可以參考下列幾項建議：

• 主要流程與其他流程分置於不同的循序圖中。千萬別在一張循序圖裡表達多條流程，避免造成圖面過於複雜，難以閱讀。
• 扮演啟動者的參與者物件放至於循序圖最左方；扮演支援者的參與者物件放置於循序圖的最右方。訊息方向盡量由左指向右，符合橫式書寫與閱讀的習慣。
• 私有操作只有物件自身可以呼叫。
• 物件之間優先透過靜態關係傳送訊息，否則可於操作中建立暫時性的關係，以便傳送訊息。透過類別之間的結合關係，類別所產生之物件之間可以傳遞訊息。
• 顯示訊息序號，有助於撰寫說明
• 兩物件之間具有組合關係時，其他物件僅能看到Whole物件，不能直接使用Part物件。
• 傳送物件，而非屬性，維持物件的封裝性
• 物件封裝了屬性，以及操作之方法，僅對外透漏公開操作。在分析規劃物件的方法時，如果需要與其他物件互動，甚至是使用物件本身的屬性或操作，切記要嚴守下列三項要件：
  1. 不得直接提及物件的屬性
  2. 也不得假設物件的執行方法
  3. 僅能夠使用到物件的操作

系統分析師可參考下述步驟來繪製循序圖：

1. 扮演啟動者的參與者物件放置於循序圖最左方；扮演支援者的參與者物件放置於物件的最右方。
2. 針對系統UC敘述裡所記載的每項流程步驟，判斷執行時需要使用到哪些資料，且可指派擁有該資料的物件負責該項工作。
3. 試著執行循序圖，以便調整流程，並且為操作加上參數。
4. 把繪製循序圖時所找到的操作及屬性，回饋給類別圖。