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

「塑模」的目標與精神，和早期系統分析強調先畫「流程圖、E-R模式」是一樣的。UML是基於物件導向設計、與非專利開放式精神的塑模規約語言，適合各種物件導向軟體開發應用，由1996年開始，在Object Management Group, OMG 的主持和資助下，UML正在逐漸成為工業標準，目前為UML 2.x版。

UML 2.x 定義的的塑模圖形(UML 2.x Diagrams)下分2大類組：結構圖形組（Structure diagrams）、行為圖形組（Behavior diagrams），原始版本以下再分14 種圖示（diagrams），但2.4版後又擴充到16個圖，定義如下：

結構性圖形組類同傳統系統分析中的「後端分析」，強調的是系統中出現的實體物件。而行為式圖形組類同傳統系統分析中的「前端分析」，強調系統模型中觸發的事件或相關行動。

一般文獻在介述時，都以結構性圖形組為先，這可能是基於資工的觀點：假設系統需求與前端分析都已經完成了，就從需求直接著手塑建後端系統模型。

但統雄老師基於「使用者導向」的系統開發觀點，建議還是先從前端分析-行為圖形組-開始塑模。

UML 2.5 新發展與限制

UML2.5 的Beta版已於 2012年底發佈，語言本身基本保持不變。然而圖表增加到總共19個了。

新增的3個圖分別是：

模型圖（Model）

這是結構圖中的一個特例（類似於自由形式的架構圖）。

表現形式圖（Manifestation）

是部署圖或者組件圖的一個特例，展示了組件在物理解決方案中是如何體現的。

網絡架構圖（Network Architecture）

這實際上是一個高層次的部署圖。

實用性爭議

但是，UML2.5 在開發社區中引起了不少爭議，因為新增部分其實際的存在價值和意義並不是很高。  

同時，依然沒有特定用於開發使用者介面、或資料庫應用介面的圖。 

因為 UML 規畫的是適用於超整合、亦即超大型、鉅細靡遺的系統設計需求。而在現實生活中，這樣的系統極稀少，對眾多中小型系統而言，根本用不到。

根據 UML 的專家 Scott W. Ambler 說，沒有見過有人用過複合結構圖(Composite structure diagram) 、交互概述圖(Interaction overview diagram) 或者通信圖（communication diagram）。

Scott W. Ambler 在2013年10月的最後一週裡，進行了一個小型調查來探索人們如何建模，總共有162個回應。每位受訪者都聽說過UML（，UML確實是無處不在的），但是只有13%的人認為UML是非常有用的，45%的人表示UML是有用的，不過他們如果沒有UML也可以完成自己的任務。另外20%的人表示UML帶來的麻煩比它的價值還要多，並且22%的人表示他們根本不用UML（儘管這些人裡10%的人表示他們曾在過去的一個月中看過一個UML圖）。

總之，OMG已經非常成功的推廣了UML，但對中小型系統分析與設計而言，傳統工具，如作業結構流程圖(Workflow Chart, WFC) 等，已足以適用了。

統雄老師的「UML 雙對象解決方案」

以上現象其實在Scott W. Ambler 開槍以前，統雄老師在1997 開始介述 UML 1.0 時，就已經發現，並提出「UML 雙對象解決方案」了。

統雄老師建議：即使舊分析工具可以適用，還是以採用 UML 為優先。

但將所有的圖，再分為A, B 兩組：

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

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

因此，UML 2.5 新增的3 圖，在本文中不再介紹，但有興趣者，可參考以下官方文件：

http://www.omg.org/spec/UML/2.5/Beta1/

核心圖示(UML core elements)

連結各種圖形的方式，稱為核心圖示(UML core elements)，在介紹各種塑模圖前，應優先認識。

導覽關係(Navigability)

能否在A頁面（或物件…）導覽到B，包括以下各種關係與圖示。

	雙邊無定義。
	A可導覽到B，B無定義。
	B不可導覽到A，A無定義。
	A可導覽到B，B不可導覽到A。
	A, B可相互導覽。
	A, B不可相互導覽。

全體/成分關係(Whole/part relationship)

集合關係(Aggregation)

表示虛擬關係，譬如以下的查詢關係，查詢表所查詢的項目理論上隸屬於查詢資料庫服務之內，但可能資料庫內並沒有這個資料，仍無損兩者的虛擬集合關係。

組合關係(Composition)

表示實體關係，譬如以下的檔案儲存關係，表示某檔案必須一定儲存在父資料夾內。

連結端的隸屬關係(Association end ownership)

表示某個頁面（表單、物件…）的一部分，譬如以下的查詢項目(query)，隸屬於查詢表單(qbuilder)的一部分。

依存關係(Dependency)

以虛線、箭頭、加一個在雙角號內的《行動參數》，譬如以下圖形表示「搜尋機制（如表單）」要求《使用》搜尋引擎。

其他的參數包括：新增、呼叫、送出…等。

如果要產生(realize)另一個介面，則使用空心箭頭。如以下圖形表示「搜尋服務（如表單）」要求《產生一個「站內搜尋」的介面》。

行為圖形組（Behavior diagrams）

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

其中最重要的就是使用個案圖 (Use Case diagram)和活動圖(Activity diagram) ，這兩者就相當於傳統作業結構流程圖(Workflow Chart, WFC)的拆開，對一般中小型系統的前端分析，也足以因應。

A 組：基本圖

使用個案圖 (Use Case diagram)

在傳統作業結構流程圖(Workflow Chart, WFC)中，第一個圖示通常是「使用者身份」選項，而在UML中，就是先把它拆開成獨立描述使用者的Use Case。

活動圖(Activity diagram)

和作業結構流程圖(Workflow Chart, WFC)中強調分析「程序」「選擇」「輸出入」「起始結束」…等，其實差不多。

起點
活動終點
資料流終點

中小型系統分析，可直接跳到結構圖形組。

交互概述圖(Interaction overview diagram)

如果是電子商務系統，或有交易需求的系統，必須製作交互概述圖(Interaction overview diagram) 。

但如果是內容網站等，沒有交易行為的，可以省略此圖。

B 組：進階圖

狀態機圖 (State Machine diagram)

互動圖形子集合（Interaction diagrams）

這是屬於行為圖形的子集合，強調系統模型中的資料流程，包括：

通信圖(Communication diagram)

時序圖(Sequence diagram)

時間圖(Timing diagram)

結構圖形組（Structure diagrams）

類同傳統系統分析中的「後端分析」，強調的是系統中出現的實體物件，包括以下7-8項。

不過，對一般中小型系統的後端分析，使用類別圖 (Class Diagram)、物件圖(Object diagram) 2種，便足以因應了。

A 組：基本圖

類別圖 (Class Diagram)

與E-R Model (Entity - Relationship)中的圖示近同，亦即資料表的分析。

譬如以下是對銀行帳戶資料表的分析。

不過，在實務上，不會單獨呈現個別資料，而還是以類似E-R Model的方式，呈現工作狂資料表間、其他系統程序間的關係。如以下對圖書館管理系統的後端-類別圖-分析。

本項圖形分析了各資料表間的導覽、集合、依存關係，以及要求產生搜尋與管理介面的程序。

物件圖(Object diagram)

「物件圖」其實就是「類別圖」的範例圖形。因為「類別圖」通常比較抽像，為了讓後續的程式師確實瞭解，所以放一、兩筆具體資料(case)為例，就是「物件圖」。

譬如以下是「教育資料管理系統」，其中包括「學院」和「學生」2個資料表的類別圖。

發展成「物件圖」，就是以「管理學院資料表」為例，包括：大學名稱、課程數、學生容量、地址…等。而「學生資料表」包括：「學生1號表」，含：姓名、學號、年齡…等，還有「學生2號表」…等。

B 組：進階圖

套件圖(Package diagram)

元件圖(Component diagram)

複合結構圖(Composite structure diagram)

部署圖(Deployment diagram)

UML Diagrams Org的詳細資料