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，直譯為「特定行為類別」，而其意譯即表示：為一種行為概念，而可視為「類別」，即未來可予定義「特性 property」、與「方法 method」。

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

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

使用個案圖 (Use Case diagram) 必須與「需求分析」環環相扣

「需求分析」中的「誰？作什麼？」，必須全部出現在「使用個案圖 (Use Case diagram) 的人形、與橢圓中。

「使用個案圖 (Use Case diagram) 的人形、與橢圓，不應該出現「需求分析」中沒有的「誰？作什麼？」。

使用個案圖 (Use Case diagram) 必須與未來的「活動圖(Activity diagram) 」環環相扣

使用個案圖 (Use Case diagram) 為概念模型。

未來的「活動圖(Activity diagram) 」為實體模型，亦即將概念發展為可操作的作業，兩者必須環環相扣。

使用個案圖 (Use Case diagram)再分為「系統」圖與「商業模式」圖２組。

使用個案圖 (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 個組織「圖書館」，並以自訂圖示表現。

系統分割與模組化

為了系統展示的簡明，以及未來分工與再整合的便利，複雜行為的使用個案，可以將整體系統再拆成幾個子系統、與再下層的行為模組，各別作使用個案圖。

如以下線上消費圖，為「線上行銷系統」之子系統«Subsystem»。

前例「餐廳系統」，點餐與買單，都是一次性、非反復的單純行為；但在線上消費時，瀏覽商品與結帳行為，可能一再反復或改變，故另分為 2 個延伸行為圖模組。

客戶分為已登錄的會員客戶，與新客戶，以「總和與隸屬關係」圖示表現。

呼叫 «include» ‧觸發«extend» ‧依存關聯(Dependency)圖示

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

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

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

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

瀏覽商品延伸行為圖模組

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

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

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

結帳行為延伸行為圖模組

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

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

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

「作什麼？」為關聯物件

前例「餐廳系統」，「作什麼？」之點餐與點飲料，但是「實體 entity」物件，亦即菜單與飲料單，都由相關使用者已輸入。

但如「倉庫管理系統」，「誰」為庫管人員，「作什麼」為檢查「庫存記錄」，則其行為係「關聯 relationship」物件，因為並無、也不應由人輸入記錄，而是由「進貨記錄 - 出貨記錄」而得。

如果需求分析之調查正確，且「進貨記錄」、「 出貨記錄」同樣由庫管人員處理，則其「作什麼」應該包括３項，且由「進貨記錄」、「 出貨記錄」«extend»到「庫存記錄」。

如果需求分析之調查「進貨記錄」、「 出貨記錄」是由其他部門：採購部、生產部所記錄，則「誰」應該包括另２個使用者，且在圖上表現出互動。

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

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

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

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

利潤來源

在工業時代初期，利潤來源主要是生產利潤。

二戰之後，市場利潤可能大於生產利潤。

而進入資訊時代後，陸續產生：管理利潤、財務利潤、數據利潤…。此即商業模式觀念興起，強調任何投資先要確定利潤來源的原因。

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

上下游整合

在資訊化初期，MIS、ERP、SCM 供應鏈管理、CRM 客戶關係管理…，為分別設計建立的系統，在商業模式觀念下，則應開始就整合入設計規畫。

前例單純的餐廳系統，發展為商業模式個案圖，就要容納入所有上下游的協力廠商，而成為下圖。

名稱上方加注 «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) 的基本差異，在於後者強調「外部使用者」與「商業」體的行為，而內部使用者屬於「商業」體的一部分，不獨立表現。

以下餐廳個案圖，如果作為商業模式使用個案圖，就是錯誤的。因為不必、且為了區隔設計目的，而不能包括侍者與會計。

整體解決方案架構時代的變革

遊戲網路一飛冲天的實例

在整體解決方案架構時代，SA工作的變革，就是除了能夠精通「TX. SA 1-2-3-4簡則」外，更應有創造商業模式的能力。

以下實例因簽有保密條款，設計文件與系統參數不能公開，但觀念可分享。

從前規畫一個線上遊戲系統，「客戶」使用者類型中「會員、非會員」差別為，只有付費會員可玩全部，而非會員只能有體驗功能。業主往往只重視爭取付費會員。

而在整體解決方案架構時代，以統雄老師指導的一個專案為例，SA便創造了「１秒成局」「S-R增強效果」的新遊戲商業模式。亦即，不僅爭取付費會員，也保留、保障一定比率的未付費會員，作為「肉角」、無意識中成為業主無償提供的「陪玩工具」。

付費會員一上線，就可以成局開玩，不必等。而且系統控制讓付費會員在無意識中總是大贏，潛意識產生來本站就是比去別站開心，以「S-R增強效果」形成長期付費的忠誠客戶。

而未付費會員，如果數量太多，會造成成本增加，形成實體企業中「業務過大而虧損」的現象。

所以在恰當時段後經，由AI 參數庫所發展的篩選器，將仍未付費會員分為A, B ２級，對黏著度高的選為A級，適量補足代幣，讓他們還可繼續陪玩下去。用個可記憶深刻的比喻：就是酒店模式，營收是來自酒客，但要有各種環肥燕瘦、數量夠多的酒女，酒客才會踴躍上門。

這個遊戲商業模式，即基於「財務管理利潤」給：如何使低成本、提供高服務能力，就是利潤。使未付費會員的本身，成為營利的來源。

遊戲網路的牌棋類，玩家最多，但因規則固定，各家在技術上，無法分出高下。但本案在商業模式改變後，立刻在上一飛冲天，成為最佳的實例。

AI 參數庫的配合

在這種商業模式之下，後端參數庫的配合便很重要。包括如何篩選適當數量的非會員，如何配對…等。

使付費會員一上線，就有人陪玩；而不要讓未付費會員擠在一起玩。

總之，在追求「財務管理利潤」的商業模式下，要使設備的投資與應用，達到最佳的效益/成本比，就是利潤的來源。

UML:統一塑模語言 

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

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

結構圖形組（Structure diagrams）

UML Diagrams Org的詳細資料