iii

緣起

很多學員和讀者跟我說，他們在書局裡、在網路上看到非常多關於 UML的書籍或文章，一百篇中有一百零一種說法。我能夠體會那種眾說紛紜

的無所適從，或許我們得試著勇敢地拋開所有的說法，認同一個自己能

夠安身立命，簡單遵循的道路。我是這麼想的！

回顧我出版第一本 UML 書—《寫給 SA 的 UML/MDA 實務手冊》 (天瓏

銷售第 1 名)，已經五年了。這五年來，拿著那本小書的概念到實務界又

跑了一圈，有了更多的體驗和心得，於是決定沉潛下來，再度將這些年

來參與專案所看、所想記錄下來，因此有了《SA 前進 UML 專案現場》

這本新書的誕生。

本書目的

這本書聚焦在，系統分析師在 UML 專案現場，如何現學現買立即使用活動

圖、使用案例圖(及敘述)、類別圖，來呈現業務流程、使用案例以及領域模

型。再者，也希望團隊成員可以人手一書，作為使用者/客戶(甲方)、建置

團隊/繪製者/觀看者(乙方)、獨立監審商(丙方)等多方溝通UML概念的基石。

本書架構

除附錄外，本書主要切分為 4 個部分共計 7 章，簡述如下：

1. 簡介

第 1 章 UML 專案現場－在 UML 專案現場，限制團隊成員使用

最少量的 UML 概念和圖示，訓誡團隊成員採用相同的作業程序，

序

p r e f a c e

iv

藉由犧牲一些自由與創意，或許可以換取團隊成員以最快速度齊步向

前走，強力挺進 UML 專案現場。

2. 建模

第 2 章 業務流程建模－使用 UML 的活動圖(Activity Diagram)，

來表達系統建置之後，所支援的新業務流程。

第 3 章 使用案例建模－使用 UML 著名的使用案例圖(Use Case

Diagram)以及使用案例敘述(Use Case Narrative)，來呈現使用

者與系統互動以獲取產品或服務的過程。

第 4 章 領域建模－使用 UML 的類別圖(Class Diagram)來表達

問題領域中的重要實體，以及實體的屬性、操作、限制、角色和

關係，用來做為系統內部重要的業務核心。

3. 模型走查

第 5 章 模型走查－程式設計師在編寫完程式碼、交付之前，可

以先進行人工的｢代碼走查｣(code walkthough)，以便確保程式碼

的品質。同樣地，系統分析師在做完每一個使用案例，並且將使

用案例涉及的領域概念，也同步萃取彙整到領域模型之後，也是

可以學習代碼走查的精神，也來先進行人工的｢模型走查｣(model

walkthough)。

第 6 章 繼續走查－經過之前的模型走查，修正了一些內容，也

跟領域專家又做了一次深度的溝通。所以，在本章中，我們將彙

整並額外補上一些疏漏的內容。

v

4. 範例

第 7 章 基金系統範例－本章內容除彙整前 2~6 章關於基金系統

的分析內容外，還會額外補充一些說明和其他分析內容，不過不

會再有更多的學理論述。

5. 附錄

附錄 A UML 官方認證－我發現很多人不知道 UML 有官方認證，

事實上，美國 OMG 協會(http://www.omg.org)於 2003 年提出了

初 級 、 中 級 和 高 級 三 個 等 級 的 UML 官 方 認 證

(http://www.omg.org/uml-certification/index.htm)。所以，本附

錄會為有興趣考取 UML 認證的讀者，簡單介紹一下 UML 官方

認證。

附錄 B 成本估算－成本估算一直都是件難事，參考過去流行的 ｢功能點｣(Function Point)估算，學者 Gustav Karner 提出了 ｢用例點｣(Use Case Point)估算來搭配物件導向技術。本附錄會

簡單提到用例點估算公式，以及相關的參考文獻。

vi

本書採用的 UML 工具

本書範例皆採用 StarUML 繪製，它最大的特色，就是免費且開源(open

source)。如果，讀者不想花錢去買龐大複雜的 UML 工具的話，試試這

套免費又簡單的工具，或許您會跟我一樣，一試成主顧！您只要連上

StarUML(http://staruml.sourceforge.net/en/)網站，就可以免費下載

StarUML 執行檔，以及別人貢獻的免費配件了。

邱郁惠

271080@gmail.com

UML Blog：http://www.umltw.com

2.1 UML 專案現場

2.2 業務流程

2.3 現場的作業程序

2.4 現場使用的圖示

業務流程建模

chapter 2

2-2 SA 前進 UML 專案現場

2.1 UML專案現場

在 UML 專案現場，系統分析師可以發覺活動圖(Activity Diagarm)比較常被用

來表達下列三種流程，分別為：

業務流程(Business Process)

系統流程(System Process)

操作流程(Operational Process)

在我的專案經驗中，倒是比較建議，倘若欲建置的系統並沒有明顯涉及到業務

流程時，其實真的沒有必要硬是要產出活動圖。當然，如果遇到建置的系統明

顯涉及到複雜的業務流程時，最好可以採用活動圖來表達業務流程，這可以帶

來下列幾項好處：

1. 系統分析師可以透過活動圖，來跟使用者或客戶溝通並確認未來系統上

線之後的業務流程。

2. 系統分析師可能會需要透過活動圖中的流程動線和控制節點，來表達使

用案例執行時的流程動線與邏輯控制。

3. 系統分析師也可以透過活動圖，找出可能遺漏的使用案例(Use Case)。

其實，多數專案時程都被壓縮的很厲害，繪製每一款或每一張 UML 圖都要花時

間、花成本，實在沒有必要為了需要交付分析設計文件，硬是繪製了一堆

UML 圖。

再者，UML 是一種用來溝通的圖形語言，倘若在使用任何一個圖示(詞彙)時，

客戶/使用者(甲方)、建置團隊/繪製者/觀看者(乙方)、獨立監審商(丙方)等多方

沒有一定水準的共同認知的話，UML 就失去了溝通的功效，而且還可能會成為

專案成員爆肝的原因之一。

因此，本章(或本書)僅聚焦在，系統分析師在 UML 專案現場，如何依樣畫葫蘆、

現學現買、立即使用活動圖來呈現重要的業務流程。此外，更希望團隊成員可

以人手一書，作為溝通 UML/SA 概念的基石。

第 2 章 業務流程建模 2-3

2.2 業務流程

2.2.1 定義

表 2-1 業務流程的定義[Wiki 百科]

Business Process(業務流程)

A business process or business method is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers.

http://en.wikipedia.org/wiki/Business_process

Wiki 百科對於“Business Process”(業務流程)的定義，十分簡單明瞭、容易

理解，此處我們就不客氣地直接引用了。從這段英文定義中，我們可以歸納出

業務流程幾個重點，如下：

業務流程主要由一組相關的活動(activity)或任務(task)所組成。

每一條業務流程通常會有一個特定的目標(goal)。

企業或組織在執行完業務流程之後，會提供特定的服務(service)或產出

特定的產品(product)。(亦即達到了特定的目標)

業務流程之所以設立特定的目標，經常是為了提供給某一個或者某一群

特定的客戶(customer)，一項具體且能夠被評價的服務或產品。

最後，我們透過心智圖(mind map)呈現上述的重點，善用圖像來協助我們加深

印象、強化記憶，如圖 2-1 所示。

圖 2-1 業務流程的定義[心智圖]

2-4 SA 前進 UML 專案現場

2.2.2 現場問題

在對於業務流程的定義有一點點初步的共識後，我們緊接著來看在 UML 專案現

場中，系統分析師在動手繪製活動圖之前，經常會遇到那些現場問題，而且又

該如何處置呢，如圖 2-2 所示。

圖 2-2 業務流程的現場問題[心智圖]

繪製？或不繪製？

一直以來，我都是非常建議系統分析師在分析階段，撥一些時間來繪製活動圖

的。不過，這樣的建議，在 UML 專案現場，也是經常出現不適用的例外狀況。

我曾經參與過兩個大型專案，專案底下當然包含了十多個、甚至數十個子系統，

這兩個專案不約而同地都規劃了一個用來維護共用資料的子系統。諸如此類的

公用系統，通常只支援非常片段的業務流程，想要從中找出完整的業務流程可

能並不恰當。如果，硬是強求系統分析師在這種情況下繪製活動圖的話，很有

可能最後就會變成使用活動圖來描述系統流程或操作流程了。

除了我們此處提到的維護資料類型的公用系統外，您在 UML 專案現場中，可

有發現其他什麼類型的系統，其實無須花費專案時程和成本，特別使用活動圖

去繪製無關緊要的業務流程呢？

在很多大型的專案中，客戶/使用者(甲方)會在合約上嚴格地規定建置團隊(乙方)需 要 交 付 那 些 文 件 。 特 別 是 在 重 要 的 系 統 需 求 規 格 書 (SRS,System

Requirement Specification) 及 系 統 設 計 規 格 書 (SDS,System Design

第 2 章 業務流程建模 2-5

Specification)中，客戶/使用者有時還會一併規範了文件的目錄章節，想要藉此

管制系統分析師與系統設計師(乙方)的作業和產出。

而且，這樣的文件規範通常會一體適用，不會因為某些系統無明顯業務流程，

就特別刪去相關章節。所以，系統分析師若遇到這類無明顯業務流程的系統時，

可以秉持著自身的專業素養，與客戶/使用者(甲方)和獨立監審商(丙方)溝通協

調，省略這項工作及產出，不要把生命浪費在這種無謂的文件上頭。

很多時候，客戶/使用者(甲方)可能不怎麼懂 UML，獨立監審商(丙方)則可能不

怎麼懂領域(domain)。在這種情況下，甲方或丙方可能都不易判斷出何時無須

繪製業務流程，這時身處其中的系統分析師(乙方)就可以跳出來，以其專業與

客戶/使用者(甲方)和獨立監審商(丙方)溝通協調。

未來流程？或現行流程？

系統分析師要是經過了第一個現場問題，確定要採用活動圖繪製業務流程之

後，可能會遇到的第二個現場問題是，需要繪製未來的業務流程還是現行的業

務流程，如圖 2-3 所示。

圖 2-3 現行流程或未來流程[心智圖]

理想上，我們會希望可以先繪製一份現行的業務流程，然後在繪製另一份未來

的業務流程。這麼一來，除了可以讓相關人員看到系統上線前後業務流程的差

異，也可以顯示建置新系統所帶來的便利與價值。

2-6 SA 前進 UML 專案現場

不過，理想歸理想、理論歸理論，在 UML 專案現場是非常現實的，一分一秒都

在燒錢，所有的工作或產出總是能省略就省略、能刪除就刪除。如果，在 UML專案現場少了某項工作或產出也無傷大雅的話，那就是跳過、刪掉、不做。

換句話說，在 UML 專案現場中，系統分析師若決定要採用活動圖繪製業務流程

的話，就請直接繪製系統建置之後的未來流程吧，別花時間繪製即將過時的現

行流程了。

業務流程？或系統流程？

系統分析師在 UML 專案現場可能會遇到的最後一個問題是，到底該用活動圖來

繪製未來的業務流程，還是繪製上線系統的內部流程呢？在錢要花在刀口上，

而且專案時程永遠都被壓縮的情況下，這個問題的答案其實不言而喻；我們當

然會建議系統分析師使用活動圖來繪製企業組織未來的業務流程，而非系統內

部的系統流程啊，如圖 2-4 所示。

圖 2-4 現場問題[心智圖]

不過，首先此處我們要先澄清一點，就是：其實在 UML 規格書中並沒有限制活

動圖只能用來表達業務流程，或者不能用來表達系統內部的系統流程。活動圖

到底想要用來表達什麼樣的流程，完全取決於繪製者。但是，有時候，繪製者

自己也不太清楚自己到底拿活動圖表達那個層級(業務或系統)的流程，甚至有

時候也會出現不分層級、混雜在一起使用的狀況。

所以，若是系統分析師在 UML 專案現場，發覺使用者/客戶(甲方)、建置團隊(乙

方)和獨立監審商(丙方)三方可能各說各話或是沒有共識時，我會建議系統分析

師翻出此處的表 2-2，甚至把這張表做成投影片，用來說明並取得甲乙丙三方

的共識。

第 2 章 業務流程建模 2-7

表 2-2 活動圖用於表達業務流程或系統流程

項目 活動圖

業務流程 系統流程

主要作用 呈現企業組織的未來流程 呈現系統內部的系統流程

人工作業 可能出現人工作業 不會出現人工作業

產製時機 需求分析階段 系統設計階段

相關文件 收錄在系統需求規格書(SRS) 收錄在系統設計規格書(SDS)

繪製者 系統分析師 系統設計師

觀看者 客戶/使用者

(系統設計師也會參考使用) 程式設計師

顆粒度 一張活動圖對應多個使用案例

(亦即將使用案例視為黑箱)

一張活動圖對應一個使用案例

(亦即將使用案例視為白箱)

其實，針對 UML/SA 的所有概念，最好都可以取得使用者/客戶(甲方)、建置團

隊(乙方)和獨立監審商(丙方)三方的共同認知，這樣三方才能協力運作，如圖

2-5 所示。

圖 2-5 三方協力運作

最後，我們再回過頭來看系統流程這個議題。想當然爾，系統流程也是十分重

要的，不過是否該要求系統設計師使用活動圖來表達系統流程，這可能有協商

討論的空間。

2-8 SA 前進 UML 專案現場

表 2-3 用於系統設計階段的活動圖與循序圖

項目 圖款

活動圖(系統流程) 循序圖(物件互動)

主要作用 呈現系統內部的系統流程 呈現系統內部的物件互動

主要特色 凸顯流程動線與控制節點 凸顯物件依序呼叫方法或函數

產製時機 高階的系統設計階段 細部的系統設計階段

相關文件 收錄在系統設計規格書(SDS) 收錄在系統設計規格書(SDS)

實作狀況 無法直接對應程式碼 可以直接對應程式碼 (有些 UML 工具可以自動產碼)

繪製者 系統設計師 系統設計師

觀看者 程式設計師 程式設計師

顆粒度 一張活動圖對應一個使用案例

(亦即將使用案例視為白箱) 一張循序圖對應一個使用案例 (亦即將使用案例視為白箱)

理想狀況是，針對系統流程較複雜的使用案例，要求系統設計師要同步產出呈

現系統流程的活動圖，但是不要針對每一個使用案例，都要求產出活動圖。附

帶一提的是，針對每一個使用案例，通常會要求系統設計師產出一張或多張的

循序圖，這已經屬於系統設計階段的事情了，所以我們就此打住，不再多談了。

2.3 現場的作業程序 我在擔任專案的 UML/SA 顧問時，通常會直接提出如圖 2-6 所示的作業程序：

圖 2-6 作業程序

step1.繪製未來的業務流程

step2.舉行確認會議

step3.產出初版的使用案例

第 2 章 業務流程建模 2-9

1. 系統分析師使用活動圖，繪製系統上線後的未來業務流程。

2. 系統分析師在產出活動圖之後，舉行確認會議，邀請客戶/使用者到場

修訂並確認業務流程的內容。

3. 在舉行過確認會議之後，系統分析師還需要產出支援業務流程的初版使

用案例圖(不含使用案例敘述)。

上述的第二步驟舉行確認會議，其實是相當重要的，建議系統分析師在會議開

始的前一周，就已經先將業務流程的電子檔(或紙本)交付給相關的使用者/客

戶，讓相關人員能夠在會議之前有時間先看過資料。

系統分析師要特別注意，使用者/客戶本身也有很多業務要做，通常不怎麼願意

花太多時間在建置團隊上頭。所以，系統分析師要把握使用者/客戶參與會議的

難得機會，盡量在會議當場就邀請使用者/客戶加入，協同修改出有共識且經過

確認的未來業務流程。

再者，有時候，使用者/客戶(甲方)在心態上也會認為自己是花了大錢請建置團

隊(乙方)來做事的，所以不見得會好聲好氣地對待建置團隊。在這種不怎麼對

等的關係中，系統分析師絕對要把握時機，趕緊跟使用者/客戶把系統上線之後

的未來業務流程確認下來。

2.4 現場使用的圖示 在這一小節中，系統分析師可以跟著我們一步一步地，一邊學習一邊繪製出表

達業務流程的活動圖。

2.4.1 起始節點

一張活動圖用來表達一條業務流程，並以活動圖中的「起始節點」(Initial Node)做為業務流程的起點。起始節點的圖示是一個實心小圓，一般習慣將起始節點

放置在活動圖面的左上角處，如圖 2-7 所示。

2-10 SA 前進 UML 專案現場

圖 2-7 起始節點

由於，橫式書寫或是西式書寫的習慣都是由左上角開始，所以將起始節點放置

在圖面的左上角處，會比較符合橫式閱讀的習慣。不過，這只是習慣用法，沒

有硬性規定一定得這樣做。

雖說內容重於一切，但是排版不佳或者表現風格不一致時，真的會讓觀看者心

生障礙，大大降低閱讀的順暢性。所以說，圖 2-8 的表示法不是不行，只是建

議系統分析師盡量統一採用圖 2-7 的表現風格。

圖 2-8 看起來比較不順暢

第 2 章 業務流程建模 2-11

使用者/客戶(甲方)看不太懂系統需求規格書(SRS)或系統設計規格書(SDS)的全數內容，這是十分正常的現象。但是，難保他們不會挑剔章節目錄以及內容

排版等等的表象，而這通常是建置團隊(乙方)沒時間去重視的部分。所以，為

了避免無謂的困擾，乾脆一開始就盡量統一呈現的風格。

在 UML 規格書中，沒有限制一張活動圖只能有一個起始節點。也就是說，一張

活動圖中可以有多個起始節點，也可能沒有起始節點。但是，為了避免遺漏起

始節點而找不到流程起點，所以我們會建議一張活動圖至少放置一個起始節點。

活動圖中可以沒有起始節點，那是因為除了起始節點外，另外有一些節點也能

夠啟動流程。所以，在活動圖中，當然就有可能沒有出現任何起始節點了。

此外，如果遇到多個起始節點的狀況時，建議拆成多張活動圖，盡量保持一張

活動圖一個起始節點的單純狀況。

2.4.2 活動終點

在每一張活動圖中，放置「活動終點」(Acitivity Final)，用來表示整張活動圖

的活動終點。活動終點的圖示是牛眼圖示(雙圓，內實外空)，如圖 2-9 所示。

延續上述「開基金戶流程」的範例，這條業務流程的最終是銀行客戶會取得基

金存摺，如圖 2-9 所示。

圖 2-9 活動終點

2-12 SA 前進 UML 專案現場

2.4.3 判斷節點

在任何一條業務流程中，都可能會遇到一些判斷節點(Decision Node)，也因此

改變了流程的動線，引發不同的動作。判斷節點的圖示是空心菱形，判斷節點

的內部請留白，不要填入任何字眼。

在 UML 初級認證考試中，有一個考題就是在考判斷節點的空心菱形圖示內部，

是否可以出現文字？答案是：不可以。這或許是因為「判斷節點」(Decision Node)和「合併節點」(Merge Node)，這兩個概念共用空心菱形圖示，才會規

定菱形要保持空白吧！後面我們會提到合併節點的概念。

此外，在每一條離開動線上頭，都要設置一個警戒條件。流程動線的圖示是帶

箭頭實線，警戒條件(Guard)則放置於中括號中，通過警戒條件(評估為真)時，

流程才能依循動線箭頭方向往下動作。

注意，設置的警戒條件必須不重疊，也不遺漏。警戒條件重疊時，可能會導致

不知該引發哪一條離開動線，這是不恰當的設計。警戒條件遺漏時，也可能會

因為所有離開動線都無法通過警戒條件，而導致流程停頓，無法繼續往下執行，

這也是不恰當的設計。

延續前面的範例，由於銀行客戶申購基金或贖回基金，都需要透過綜合存款帳

戶把款項匯入或匯出，所以會需要用到綜合存款帳戶。因此，銀行客戶一要求

要開基金帳戶時，理財專員就會立即跟銀行客戶確認，是否有在本銀行開過綜

合存款帳戶，如圖 2-10 所示。

圖 2-10 判斷節點