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

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

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

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

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

利潤來源

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

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

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

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

上下游整合

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

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

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

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

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

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

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

商業模式設計：優化程序

商業模式設計更可以優化現有的作業流程，如以下某新建機場，先考察現有機場的營運後，發現2個問題：

1. 當前出境櫃臺，只分為【團客】與【散客】，而在觀察中，發現旅客中存在某些特殊現象，是否可以增加更貼心的服務呢？

2. 出境櫃臺前大排長龍，是否可以有提升效率的方法呢？

以上 2 項問題解決的構想，就可用以下商業模式使用個案圖呈現，作為討論與實施的基礎。

解決以上 2 項問題，第一、就是增加了【無障礙】服務型商業模式，特別突出【兒童】與身心障礙者的旅客。注意，凡是新創構想，也另行必須增加【子模組】。

第二、除了傳統的櫃臺辦理外，再增加【自助辦理】，也就是增加自助 Check-in 機臺。

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

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

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

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

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

整體解決方案架構之核心就是必須與商業模式整合，如果能夠創造新利潤，必定須借助創新的發想與能力。

唯本文作者在指導資訊系統發展數十年後發現，對線上使用者之調查與需求分析，多數只能反映制式作業程序；少數會提出抱怨，即值得注意與改進的問題；而極少能夠提出創新解決的方案。

在過去系統分析與設計之觀照，僅限於內部時，或已足夠。但要與商業模式整合，發展整體解決方案架構時，需求分析必須更借助 SA, Solution Architect 方案架構師個人或團隊的研究能力、與領域知識。

僅靠基礎的「需求分析書」，已無法滿足設計商業模式使用個案圖 Business Use Case diagram，必須再投入最新的管理知識、收集資訊的研究方法知識、各種數據統計與分析的能力。

由於領域知識與客戶個性的需要，可能更需配合參與觀察法、舉辦品管圈等，以收集設計的資訊。

遊戲網路一飛冲天的實例

資訊領域存在【資科思維】和【資管思維】，【資科思維】就是只講寫程式、作產品，但歷史經驗顯示，除非技術為世界頂尖，無人能及，即使有產品，不見得能夠暢銷，不一定對組織有利。而【資管思維】就是能夠思考【整體解決方案架構】，即使是一般技術水準的產品，也可以形成高獲利商業模式，促進組織成長發展。

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

在【遊戲網路】領域，各家的資科技術，其實差距有限，尤其【手遊類】的遊戲，更屬於門檻技術。

臺灣第一家網路遊戲公司，是早於1998年便成立的【宏碁戲谷】，因為【手遊類】遊戲的玩家最多、市場最大，第一步當然是進攻【手遊類】遊戲。宏碁的資科程式高手比比皆是，進入市場又早，理論上應可一統江山。但這個領域的先天程式門檻就是不高，在眾多競爭者紛紛進入後，宏碁缺乏【商業模式】的因應，坐等一蹶不振，硬撐到 2006 年廉價賣掉，而大陸區的業務根本賣不掉，至 2007 完全認賠倒閉了。

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

我有一位學生在一家【手遊類】遊戲公司服務，原來公司業績也是平平。來上過課後，向老闆建言導入新創商業模式觀念。

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

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

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

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

所以在恰當時段後，經由AI 參數庫所發展的篩選器，將仍未付費會員分為A, B ２級，對黏著度高的選為A級，適量補足代幣，讓他們還可繼續陪玩下去；而B級，就讓他們淘汰，或慢慢等，不要占用營業資源。

由於本案業主來自社會基層，用專業術語說明聽不下去，甚至會打瞌睡。所以，在建議業主必須更新商業模式時，改用了個一般人可記憶深刻的比喻：就是酒店模式，營收是來自酒客，但要有各種環肥燕瘦、數量夠多的酒女，酒客才會踴躍上門。酒女太少，或酒女太醜，裝潢再豪華，酒客也不喜歡去。業主聽了以後，就欣然認可了。這個有趣的過程，說明 Solution Architect 方案架構師不僅需要廣博專業知識，還需要因時地人制宜的溝通技巧。

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

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

社媒平臺也是以商業模式取勝

社媒平臺建構就資科程式觀點，程度也是普普，所以大量興起、大量倒下。連 Google+ 這種技術素質極高、財大氣粗的背景都撐不下去。只有 Facebook 和 Linkedin 各領風騷，都是因為商業模式。

Facebook 在起步時，用的是通俗的 PHP 程式，我甚至可以在使用者端改它的呈現方式。但它的【合作鏈與開放經營商業模式】、或可稱為【大公園免費擺攤商業模式】，使它能在短期內壯大，至今仍相對獨霸。

Linkedin 則是在輾轉多年、瀕臨倒閉時，突然獲得大量金援，改革為【人力資源】 Niche 商業模式，才脫胎換骨成為人資特色霸主。

AI 參數庫的配合

以上各種商業模式，後端參數庫的配合便很重要。如遊戲網站如何篩選適當數量的非會員，如何配對…等。使付費會員一上線，就有人陪玩；而不要讓未付費會員擠在一起玩。

Facebook 所以能夠搞出【劍橋醜聞】，也就是竟能操作選舉，就是靠 AI 參數庫。而 Linkedin 能夠成為人力仲介中心，當然也是 AI 參數庫，否則只能像是其他一大堆提供大量原始資料的網站，應用效益很低。

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

UML:統一塑模語言 

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

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

結構圖形組（Structure diagrams）

UML Diagrams Org的詳細資料