UML:統一塑模語言/開發圖神掌

在資訊系統愈來愈往大規模化，複雜化的發展趨勢下，促成了統一塑模語言（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 已於 2012年底發布，UML 2.5.1 則在 2017 年底發布，語言本身基本保持不變。然而圖表調整為「官方（即確認）圖」1個，與「非官方圖」若干個，亦即尚待應用與回饋後確認。

結構性圖形組，即「TX. SA 1-2-3-4簡則」中的「資料流與資料庫分析」，類同傳統系統分析中的「後端分析」，強調的是系統中出現的實體物件。

而行為式圖形組，即「TX. SA 1-2-3-4簡則」中的「作業流程分析」，類同傳統系統分析中的「前端分析」，強調系統模型中觸發的事件或相關行動。

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

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

當前的 UML，定義如下，黑色是「官方（即確認）圖」，藍色是「非官方圖」：

UML 2.5 新發展與限制

UML 最新版是在 2017 年底發布的UML 2.5.1，語言本身基本保持不變。然而圖表增加了「非官方圖」若干個，亦即尚待應用與回饋後確認。

其中可能會較快發展為官方圖的分別是：

模型圖（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，但對作中小型系統分析與設計的 Software Lab 而言，認為傳統工具，如作業結構流程圖(Workflow Chart, WFC) 等，已足以適用了。

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

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

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

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

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

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

因此，UML 2.5 新增的非官方圖，在本文中不再介紹，但有興趣者，可參考以下官方文件：塑模圖形(UML 2.x Diagrams)。

核心圖示(UML core elements)

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

導覽關係(Navigability)

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

	雙邊無定義。
	A可導覽到B，B無定義。
	B不可導覽到A，A無定義。B譬如外部使用者物件。
	A可導覽到B，B不可導覽到A。A譬如管理員物件。
	A, B可相互導覽。
	A, B不可相互導覽。

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

全體與成分關係，再分為以下的表現方式。

集合關係(Aggregation)

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

同時，此圖也表示「可抽換」的觀念。

組合關係(Composition)

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

而成分物件必須與全體必須共存。

其中 File 的「*」號表示 Multiplicity，即有多個檔案，數量可能 0~n。如果至少有 1 個檔案，表示應改為：「1..*」。

而 Folder 的 1，表示只有 1 個檔案夾。亦即如果刪除此資料夾，所有檔案均將被刪除。 

全體物件還有1 個特別的 "at most one" 表示法：「0..1」，即可能「無」或「最多1個」。

以下圖為：有許多員工，各自最多屬於一個部門，或直屬中央。如果某 1 部門撤除，各員工是被釋出，但不會消失。

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

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

因為前者存在，後者才存在。有查詢表單，才出現查詢的項目。

依存關係(Dependency)

先有一個動作，再產生一個物件。

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

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

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

UML:統一塑模語言 

行為圖形組（Behavior diagrams）

結構圖形組（Structure diagrams）

UML Diagrams Org的詳細資料