6.2 UML的基本概念

6.2.1 UML是什麼

系統模型可以使用自然語言、表格、數學式、圖形或其他形式建立。其中，圖形模型能將系統元素及其關係集中呈現，因此常被用於系統分析與系統設計。

但是，如果不同的人任意使用不同圖形及線條，同一張圖可能產生不同解讀。如果沒有規定，那就必須每一次都重新定義。例如：

• 長方形代表外部系統，還是系統內部元件？
• 實線代表一般關係、資料流向，還是訊息傳遞？
• 箭頭表示控制方向、依賴方向，還是執行順序？
• 圖形包含某個角色，是否表示該角色可以使用所有功能？
• 兩個元素相連，是否代表其中一個一定先於另一個執行？

如果圖形的表示方式缺乏共同規則，讀者就必須先猜測繪圖者的意思，模型也難以成為可靠的溝通工具。為解決此一問題，統一塑模語言（UML）提供一套標準化的圖形元素、關係及語意，可以用來描述、溝通及記錄系統。系統分析師與系統設計人員可以依照建模目的選擇適當的UML圖，從不同觀點呈現系統。

UML可以應用於資訊系統、軟體系統、嵌入式系統及其他複雜系統。雖然UML與物件導向分析及設計關係密切，但UML的用途不僅止於程式設計。它也可以呈現：

• 外部角色與系統服務
• 業務及系統活動
• 領域概念及其關係
• 參與者或物件之間的互動
• 物件的狀態與轉換
• 軟體元件及相依關係
• 軟體與執行環境的配置

因此，學習UML的重點不是背誦圖形符號，而是理解：

統一塑模語言（Unified Modeling Language，UML）是一套用來建立系統模型的標準化視覺語言。它提供一組具有特定語意的模型元素與關係，使建模者能從不同觀點描述系統。UML的三個英文字，分別為「統一」「塑模」「語言」，這三個詞可以解釋如下：

• 「統一（Unified）」表示它整合並標準化多種建模觀念與表示法，使不同工具、方法及專業人員可以使用較一致的模型語言。
• 「塑模」表示針對真實或預計建立的系統進行有目的的抽象，選擇需要呈現的元素、特徵與關係。
• 「語言」表示UML具有自己的基本詞彙、表示規則與語意。圖形不是任意裝飾，圖形的使用不是單純的美學考量；不同的圖形、線條、箭頭及標記通常具有特定意義。

UML主要可以支援以下工作：

§ 視覺化

UML可以將原本分散在文字需求、訪談紀錄及設計說明中的部分資訊轉換成圖形，使角色、結構、流程或互動關係更容易被觀察。

§ 說明

UML模型可以說明系統的特定觀點。例如：

• 使用案例圖說明哪些外部參與者會使用哪些系統服務。
• 活動圖說明活動、決策與流程如何進行。
• 類別圖說明領域概念或軟體類別，並顯示其之間的關係。
• 循序圖說明參與者或物件如何依時間順序互動。
• 狀態機圖（State Machine Diagram，亦常簡稱狀態圖）說明某個物件可能具有的狀態及轉換。

§ 支援溝通

系統分析師可以利用UML模型與利害關係人、設計人員、開發人員及測試人員討論系統。模型提供共同的討論對象，使參與者可以指出：

• 遺漏的角色
• 不正確的關係
• 不完整的流程
• 不合理的狀態
• 與需求不一致的系統行為

§ 記錄分析與設計成果

經過確認的UML模型可以保存重要的分析或設計決定，並與需求規格、驗收準則及其他專案文件建立追蹤關係。

不過，必須注意UML並不具有以下功能：

§ UML不是開發方法

UML不會規定專案必須採用瀑布式、迭代式、敏捷或其他開發方法，也不會規定何時一定要建立哪一張圖。不同開發方法都可以使用UML，但使用方式、建模深度及更新頻率可能不同。

§ UML不是開發流程

UML不會自動告訴專案團隊：

• 應先蒐集哪些需求
• 應訪談哪些利害關係人
• 需求衝突應如何決定
• 模型應由誰審查
• 系統應採用哪一種架構
• 何時可以進入程式實作

這些問題需要由專案方法、組織規範及專業判斷決定。

§ UML不是程式語言

UML模型可以支援程式設計，也有些工具能依模型產生部分程式碼或從程式碼建立模型，但UML本身不能取代完整的程式實作。

§ UML不能保證模型正確

即使圖完全符合UML表示法，模型內容仍可能：

• 超出系統範圍
• 遺漏重要需求
• 誤解利害關係人的目標
• 使用錯誤的角色名稱
• 包含沒有需求來源支持的功能
• 與其他模型或需求規格不一致

因此：

6.2.2 模型、模型元素與圖

日常討論中，人們常把「模型」與「圖」視為同一個概念，但兩者並不完全相同。

§ 模型

模型是對系統某些特徵的抽象表示。模型可以包含：

• 元素
• 元素的屬性
• 元素之間的關係
• 約束條件
• 說明文字
• 多個彼此相關的圖

例如，Case M01的使用案例模型可能包含：

• 隊長
• 評審
• 競賽承辦人員
• 校園身分驗證系統
• 提交競賽報名
• 分派評審
• 評定參賽專題
• 各參與者與使用案例之間的關係
• 使用案例的詳細文字描述

這些內容共同構成使用案例模型，不只是其中一張使用案例圖。

§ 模型元素

模型元素是模型中具有特定意義的基本單位。例如：

• 使用案例模型中的參與者與使用案例
• 活動模型中的活動、決策及控制流程
• 類別模型中的類別、屬性及關聯
• 互動模型中的生命線與訊息
• 狀態模型中的狀態、事件及轉換

同一個模型元素可能出現在多張圖中。例如，「評審」可以同時出現在整體使用案例圖及評分作業的局部使用案例圖中。這些圖中的「評審」代表同一個角色，不表示存在兩個不同的評審角色，只是同一個模型元素在不同圖中出現。

§ 圖

圖是模型的特定視圖，用來呈現為某個目的所選擇的模型元素與關係。一張圖通常不需要顯示模型中的全部內容。例如，Case M01可以建立：

• 整體使用案例圖：呈現主要參與者與核心系統服務。
• 報名作業使用案例圖：集中呈現團隊建立、資料修改及文件上傳等流程。
• 評分作業使用案例圖：集中呈現評審分派、評分及更正申請。
• 結果管理使用案例圖：集中呈現結果確認與公告。

這些圖可以來自同一個使用案例模型，但各自服務不同的閱讀與溝通目的。

模型與圖的關係可以概括如下：

一般繪圖軟體通常將各圖中的圖形視為彼此獨立的物件，建模者必須自行維持名稱與內容的一致性；專業建模軟體則可集中管理模型元素，並讓同一元素出現在不同圖中。當元素名稱改變時，相關圖也可以同步更新。

無論使用哪一種工具，都應避免把「圖畫好了」直接視為「模型完成了」。模型是否完整，仍需檢查：

• 元素是否具有清楚定義
• 關係是否符合其語意
• 圖與文字描述是否一致
• 模型元素是否具有需求依據
• 不同圖是否使用一致名稱
• 模型是否能回答原本的分析問題

6.2.3 UML圖的主要類型

UML圖可以概分為結構圖（Structure Diagram）與行為圖（Behavior Diagram）。部分的行為圖亦可進一步歸納為互動圖（Interaction Diagram）。

§ 結構圖

結構圖著重系統在某個時間點所具有的組成元素及其關係，主要回答：

常見結構圖包括：

系統分析時，類別圖可用來建立領域模型；系統設計時，類別圖、元件圖及部署圖則可進一步描述軟體結構與執行環境。

§ 行為圖

行為圖著重系統隨事件、活動或使用情境所表現的行為，主要回答：

常見行為圖包括：

使用案例圖著重於外部參與者及其使用目標；活動圖著重於流程的進行方式；狀態圖則著重於特定物件如何因事件而改變狀態。

§ 互動圖

互動圖是行為圖的一類，著重參與者、物件或系統元件之間如何交換訊息，主要回答：

常見互動圖包括：

UML將互動圖歸入行為圖之下。因此，「結構圖、行為圖、互動圖」並不是三個完全並列的分類；互動圖是行為圖中專門表達訊息互動的一組圖。

§ 本書採用的主要模型

系統分析與設計不需要使用全部的UML圖。本書會根據教學與案例需要，主要採用：

此外，系統分析也可能使用其他建模方法，例如：

• 資料流程圖（Data Flow Diagram，DFD）
• 實體關係圖（Entity-Relationship Diagram，ERD）
• 商業流程模型與標記法（Business Process Model and Notation，BPMN）

這些圖可以與UML模型搭配使用，但它們並不是UML圖。

6.2.4 UML的表示規則、語意與使用原則

要正確使用UML，不能只辨識圖形外觀，還需要理解表示規則與模型語意。

§ 表示法

表示法（Notation）是模型元素在圖上的呈現方式，讓讀者辨識圖中的元素類型。例如：

• 參與者通常以人形符號或帶有`«actor»`標記的長方形表示。
• 使用案例通常以橢圓表示。
• 類別通常以分隔欄位的長方形表示。
• 狀態通常以圓角長方形表示。
• 不同關係使用不同線條、箭頭或標記表示。

§ 語意

語意（Semantics）是模型元素或關係實際代表的意思。

例如，在「使用案例圖」中，參與者與使用案例之間具有關聯，表示該參與者會參與該使用案例。但這條線通常不表示：

• 資料由參與者流向使用案例
• 參與者一定先執行某個動作
• 使用案例會主動呼叫參與者
• 參與者擁有該使用案例
• 使用案例只能由這個參與者使用

如果只模仿圖形外觀而不了解語意，就可能畫出形式正確但意思錯誤的模型。

§ 模型名稱與識別

UML模型中的元素應使用清楚且一致的名稱。例如：

• 參與者名稱應表達角色，例如「隊長」或「競賽承辦人員」。
• 使用案例名稱應表達參與者希望完成的目標，例如「提交競賽報名」。
• 活動名稱應表達正在執行的工作。
• 類別名稱應表達領域概念或系統中的責任主體。
• 狀態名稱應表達物件在特定期間成立的情況。

若模型需要與需求規格建立追蹤，可以加入識別碼，但識別碼不應取代有意義的名稱。例如：

會比只寫代號更容易閱讀與討論：

§ 圖中的方向不一定代表執行方向

不同UML圖對線條與箭頭的定義不同。讀者不能只依一般直覺解讀箭頭。例如：

• 使用案例圖的關聯通常不表示時間順序。
• 類別圖的關聯方向不等同於資料流向。
• 相依關係的箭頭通常指向被依賴的元素。
• 循序圖則透過生命線由上而下呈現時間推進。

因此，解讀線條或箭頭時，需要先確認：

1. 這是哪一種UML圖？
2. 線條表示哪一種關係？
3. 箭頭方向在這種關係中代表什麼？

§ 一張圖應具有清楚的範圍

一張UML圖應標示或說明：

• 圖名
• 建模目的
• 涵蓋範圍
• 適用的系統或子系統
• 必要的版本或狀態資訊

同一張圖若同時放入過多角色、功能、類別及技術元件，會使模型難以閱讀。必要時可以建立整體圖及多張局部圖，但不同圖之間必須保持名稱與語意一致。

§ 圖中不需要呈現所有細節

UML提供許多元素、關係及標記，但建模者不必把所有可用符號都加入圖中。是否呈現某項資訊，應取決於它是否能協助回答建模問題。例如，若使用案例圖的目的只是確認參與者與系統服務，通常不需要同時加入：

• 畫面欄位
• 資料表名稱
• 程式類別
• 網路協定
• 伺服器配置
• 完整操作步驟

這些內容即使與系統有關，也可能屬於其他模型或文件。

§ UML圖需要搭配文字說明

圖可以快速呈現元素及關係，但不一定能完整記錄：

• 業務規則
• 詳細限制
• 前置與後置條件
• 替代與例外情境
• 非功能需求
• 決議理由
• 待確認事項

因此，UML圖通常需要搭配：

• 元素定義
• 使用案例描述
• 流程說明
• 模型假設
• 限制條件
• 需求追蹤資料

§ 需驗證AI生成的UML

生成式AI可以根據文字內容產生候選模型、模型說明，或以PlantUML、Mermaid等文字語法表達UML圖。然而，AI可能誤判建模目的、混用不同圖的表示法，或建立不符合需求依據的模型元素與關係。

因此，使用AI生成的UML模型時，至少需要確認：

• 建模目的是否明確
• UML圖類型是否適合
• 模型元素是否具有需求依據
• 表示法與語意是否正確
• 名稱是否與需求規格一致
• 模型是否遺漏重要內容
• 是否加入沒有來源支持的假設
• 是否與其他模型及文字規格一致

UML的核心價值不在於建立大量的圖，而在於提供一套較一致的模型語言，使系統相關人員能從不同觀點理解、分析與設計系統。

UML的基本觀念可以整理如下：

因此：