UML:統一塑模語言/行為圖形組神掌

在資訊系統愈來愈往大規模化，複雜化的發展趨勢下，促成了統一塑模語言（UML, Unified Modeling Language）的誕生。「塑模」的意思就是以圖形的方式，先將系統的功能與結構畫成「模型」與藍圖，然後再依據藍圖進行實體開發。

UML 2.x 定義的的塑模圖形(UML 2.x Diagrams)下分2大類組：結構圖形組（Structure diagrams）、行為圖形組（Behavior diagrams）。

統雄老師建議：將 2 圖組，再分為A, B 兩組：

A 組：基本圖，適用所有中小型系統分析與設計。亦即，並非所有的圖都要用到。

B 組：進階圖，針對大型系統分析與設計，再使用。

行為圖形組（Behavior diagrams）

類同傳統系統分析中的「前端分析」，強調系統模型中觸發的事件或相關行動，包括：使用個案圖 (Use Case diagram)、活動圖(Activity diagram) 、狀態機圖 (State Machine diagram) 和互動圖形子集合（Interaction diagrams），在子集合內又包括4種圖。

其中最重要的就是使用個案圖 (Use Case diagram)和活動圖(Activity diagram) ，前者是UML 特別定義的概念模型設計，後者就相當於傳統作業結構流程圖(Workflow Chart, WFC)，對一般中小型系統的前端分析，已足以因應。

A 組：基本圖

使用個案圖 (Use Case diagram)

使用個案圖 (Use Case diagram) 在分類上屬於行為圖形組（Behavior diagrams） ，但 UML 認為它也定義了結構圖形組（Structure diagrams）的基礎，所以是跨行為與結構的最重要圖形。

使用個案圖以人形、橢圓、與連結線為主：人形表現使用者 actors，actors 可譯為「行為人」，本系列講義為維持概念一致性，仍稱為使用者。

橢圓就是 use case，由於是專有名詞，直譯「使用個案」，在中文上未盡達意。其英文的白話為 behaviored classifier，意譯即表示特定行為類別。

人形與橢圓中間的直線，稱為連結 association。

這個圖，就是表現「需求分析」的：誰？作什麼？

使用個案圖 (Use Case diagram) 再分為2組：一般使用個案圖 (Use Case diagram) 、或稱系統使用個案圖 (System Use Case diagram) ，以及商業模式使用個案圖 (Business Use Case diagram) 。

一般/系統使用個案圖  Use Case diagram / System Use Case diagram

一般/系統使用個案圖相當於「需求分析書」的視覺化，定義使用者類別，與其在系統上的行為，通常會表現互動行為的雙方。

在傳統作業結構流程圖(Workflow Chart, WFC)中，第一個圖示通常是「使用者身分」與其可從事行為選項，而在UML中，就是描述使用者的 Use Case 圖。

如以下餐廳系統的行為簡化圖。

矩形為 UML 元素圖框 elements frame，在此稱為 subject。框內左上方為 subject 名稱，此為餐廳。

框外左側人形，為需求使用者：人形下方為名稱-顧客；行為：點餐、點飲料、付帳。

框外右側人形，為供給使用者：人形下方為名稱-廚師；行為：烹飪。

自訂圖示

UML 允許自訂視覺輔助圖示，如以下的線上圖書館查詢系統。名稱上方可以«»加注，此為整個圖書館系統的一個模組。

需求使用者：讀者；行為：帳戶管理、搜尋、預訂、重設、意見反映。

供給使用者：相應提供需求的不是個人，而為 1 個組織「圖書館」，並以自訂圖示表現。

呼叫 «include» ‧觸發«extend» ‧延伸行為圖

複雜行為的使用個案，可以將整體系統再拆成幾個子系統、與再下層的行為模組，各別作使用個案圖。

如以下線上消費圖，為「線上行銷系統」之子系統«Subsystem»，客戶分為已登錄的會員客戶，與新客戶。

會員客戶「登入後」（登入行為，另以延伸行為圖呈現）可瀏覽商品、或購買。如果進行購買行為，會再「呼叫」 «include» 瀏覽商品與結帳行為。 «include» 所指向的行為，都是出發行為的子集合。注意：結帳行為沒有和客戶連結，亦即，如果客戶必須先進行購買行為，才會產生«include»結帳行為。

而新客戶可以選擇瀏覽商品、或登錄為會員。

瀏覽商品、結帳行為登錄為會員，所需要的驗證 Authentication 與帳戶管理 Identity，前者可以是個服務機制 «Service»，後者就是會員名單管理，兩者均可視為機器人。

結帳行為的支付者，包括：信用卡與 PayPal。

其中瀏覽商品與結帳行為，可再分為 2 個延伸行為圖。

瀏覽商品延伸行為圖，可以經由客戶進行：搜尋、展示結果、瀏覽推播產品、加入購物車、提供期待產品清單行為，而被「觸發」«extend» 產生瀏覽商品。

在瀏覽推播產品、提供期待產品清單時，會「呼叫」 «include» 客戶驗證。

客戶驗證後，可「觸發」«extend» 加入購物車。

結帳行為延伸行為圖，結帳行為會「觸發」«extend»：客戶驗證、確認購物清單、計算費用與運送方式、付款。

其他相應細節，請讀者嘗試解讀。

其中單一登入Single Sign-on，因為本圖僅為「線上行銷系統」之子系統«Subsystem»之一，可能還存在其他：抽獎子系統、事件行銷子系統…等，僅需在1個子系統登入，就可以遊走各子系統。

商業模式使用個案圖 Business Use Case diagram

與統一軟體開發過程 Rational Unified Process, RUP

UML 採用了統一軟體開發過程 (Rational Unified Process, RUP )觀念，亦即不僅分析設計特定系統功能，而要發展為前文所介述的 Solution Architecture 整體解決方案架構，將關聯行為整合，在系統發展前，先提出整體的商業模式。

相較於傳統分析第一步為畫流程圖，UML 強調可在系統設計之前，再先建立一個更廣闊、更整合的「程序概念」模式、或商業模式。

為表現商業模式的使用個案圖示，為在橢圓右側加 1 條斜線，下例假設為登入行為：

以上單純的餐廳系統，化為商業模式，就要容納入所有上下游的協力廠商，而成為下圖。

名稱上方加注 «Business» 表示是商業模式使用個案圖。

在整體的商業模式設計中，是以外部系統使用者為考量，包括 6 類：客戶、行銷協力、食材供應協力、員工與召員、維修協力。而內部使用者，如廚師，則會被省略。

模式的修正：UML 在整體解決方案架構企畫的優勢

本模式提出後，經過公司會議討論，發現行銷協力的績效評估，必須與每次行銷活動所獲得的新客戶產生連結，所以加入潛在客戶使用者。而維修協力並非經常性活動，加入系統可能造成系統虛胖，也增加風險，所以剔除這類使用者，修正為下圖。

UML 工具可以在原始起點修正商業模式，是為 UML 在整體解決方案架構企畫的特殊優勢。

複雜程序商業模式設計

較複雜程序的商業模式設計，如以下機場登入模式圖。

一般/系統使用個案圖 Use Case diagram / System Use Case diagram

與商業模式使用個案圖 Business Use Case diagram 的基本差異

一般/系統使用個案圖 (Use Case diagram / System Use Case diagram) 與商業模式使用個案圖 (Business Use Case diagram) 的基本差異，在於後者強調「外部使用者」與「商業」體的行為，而內部使用者屬於「商業」體的一部分，不獨立表現。

以下餐廳個案圖，如果作為商業模式使用個案圖，就是錯誤的。因為不能包括侍者與會計。

UML:統一塑模語言 

行為圖形組（Behavior diagrams）1：使用個案圖  Use Case diagram

行為圖形組（Behavior diagrams）2：活動圖 Activity diagram 與進階圖

結構圖形組（Structure diagrams）

UML Diagrams Org的詳細資料