UML, Unified Modeling Language

如果你不想讀700頁的教科書，才知道什麼是MIS，本系列講義可以讓你立刻認識「MIS 管理資訊系統」的目標、開發方法、實務應用，提供「TX 1-2-3-4簡則」作為「系統分析與設計(SA&D)」最簡明的指導，特別適合中小型系統之開發與分析。

並隨時更新最新發展，如UML, NoSQL資料庫, 決策支援, 決策參數庫, 知識管理, 與大數據數位分析...等。
MIS 發展到今日，已不限於狹義的管理-即進銷存，而可廣泛應用於各領域，也可簡稱為 IS。本系列文章使用 MIS 一詞，是取知識歷史承傳的意義，各項討論可適用於廣義的資訊系統 IS。

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

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

行為圖形組支援商業模式整合

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

因應 SA 擴大發展為 Solution Architecture，UML 的行為圖形組特別能夠支援資訊系統與商業模式的整合，以提供最適與最完整的服務。

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

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

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

UML 2.5 新發展與限制

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

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

模型圖（Model）

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

表現形式圖（Manifestation）

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

網絡架構圖（Network Architecture）

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

實用性爭議

但是，UML2.5 在開發社區中引起了不少正反爭議，正方是整體而言，UML已成為相對最被採用的工具。而反方則認為新增部分其實際的存在價值和意義並不是很高。同時，強調總體，忽略個體，沒有特定用於開發使用者介面、或資料庫應用介面的圖。

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

根據 UML 的專家 Scott W. Ambler 說，根據調查在2013年底，已經有超過半數的系統分析採用UML，但沒有見過有人用過複合結構圖(Composite structure diagram) 、交互概述圖(Interaction overview diagram) 或者通信圖（communication diagram）。

國際各系統開發網站，對UML都有激烈的討論，OMG已經非常成功的推廣了UML。迄2021底，很有代表性的評論就是「愛恨交織 Love-Hate Relationship」而其理由卻是相同，UML 具備所有系統分析工具需求的優勢，也因此龐大複雜，要用它變成先要有相當學習時間。

尤其對極端派的「Agile 敏捷系」，作中小型系統分析與設計的 Software Lab 而言，認為傳統工具，如作業結構流程圖(Workflow Chart, WFC) 等，已足以適用了。但中立派的「Agile 敏捷系」，認為不能完全拋棄開發程序文件、模型圖等，而UML 仍具備標準化、易結構化的優勢。

BPMN 商業流程模型和標記法

由於 UML 的龐大，OMG 於 2005 年再與其他組織合作，推出「商業流程模型和標記法 BPMN (Business Process Model and Notation)」，是作業結構流程圖(Workflow Chart, WFC) 的擴充與更新，也等同是 UML 眾多模型圖中的一個。

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

以上現象其實在Scott W. Ambler 開槍、各網站評估之前，統雄老師在1997 開始介述 UML 1.0 時，就已經發現，並提出「UML 雙對象解決方案」了，以調和 Waterfall Model，與 Agile software development 兩種系統開發思想的解決之道。

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

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

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

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

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

核心圖示(UML core elements)

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

總和與隸屬關係(Generalization)

一個總和分類器 general classifier 或 superclass 與隸屬其各分類器的關係，以空心箭頭表示。

如以下，帳戶包括3種：支存帳戶、儲存帳戶、信貸帳戶。

UML

分開的線條也可以合併。

UML

以上 UML 各種塑模圖的結構，也採用了此空心箭頭圖示。

導覽關係(Navigability)

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

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

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

Relationship 即物件的關聯，在一個或多個集合中，全體與成分可分為以下的多種關聯。

多重性 Multiplicity 與基數 Cardinality

由於有全體與成分，就會出現多重性 Multiplicity 與基數 Cardinality（注：也有文獻將其譯為「勢」）的問題。

基數 Cardinality 就是1個集合中，具有元素的數量。

多重性 Multiplicity 就是1個集合中，可能具有何種「基數 Cardinality」的範圍。

多重性 Multiplicity	簡寫	基數 Cardinality
0..0	0	0，一定沒有。
0..1		0個或1個。
1..1	1	有，且只有1個。
0..*	*	0或更多未知數量。
1..*		至少有1個。
9..9	9	有9個，且只有9個。
x..y		至少有 x 個，且最多有 y 個。