為什麼掌握 UML 建模是成為程式設計高手的一條捷徑？

Agile2-張恂老師2015-07-30 16:39:18

原文出處：

UMLGreatChina-FAQ

先簡單回答，因為 UML 建模是進行

OOAD，學習運用設計模式，精讀原始碼，敏捷地思考和溝通軟體設計方案的一把利劍，也是成為軟體架構師的必要條件和技能，而這些是普通碼農所不掌握或不屑掌握的。一旦熟練掌握了 UML 建模技術，恭喜你，你已超越了江湖上 70% 的碼農！

誤解

看到有網友說：

學會UML並不會自然的學會建模。學UML只是學會了一種模型的表示方法。

出現這種情況，一定是遇到了不會教的老師，或者學得不好的學生。

沒錯，UML本身只是一個語言，然而去學UML，當然不能只學語言和表示方法（幾張圖和一堆符號），同時還要學利用UML建模的方法、流程和技術（如UP、敏捷建模、OOAD等），這些對應著（軟體或）系統的分析與設計方法。

UML（語言）與UML建模（UML Modeling， or Modeling in UML）是兩個不同的概念。而正確地學UML=學UML建模，不應該只學語言、模型的表示方法，還應該學建模的方法和技術；學會了UML建模，自然就會建模了。

原因一、基於 UML 建模的 OOAD 是 OO 軟體架構師的基本功

Visual Modeling（視覺化/圖形化建模）對於軟體開發（尤其擁有大量程式碼的複雜、大中型系統和產品）非常重要，而利用建模技術有效地進行系統分析與設計，能夠有條不紊、從容不迫地應對、解決複雜和棘手的軟體設計難題正是程式設計高手們所擅長的。

軟

件開發本質上是一種思維遊戲（張恂：Software development is a mind

game。），程式程式碼的好壞其實是開發者思維的體現。普通碼農與程式設計高手的主要差別正是在於思維，尤其在抽象思維、空間思維、邏輯思維等方面。程式設計高手

如何程式設計？拿到一個需求，腦子裡一片空白或者亂糟糟的就開始寫程式碼？當然不是。

在思考能力上，針對同一個軟體設計問題，架構師常常比一般

碼農想到的更多，更快，也更正確，而且具有預見性。透過建模來進行系統的分析與設計（如針對 OO 軟體的

OOAD，即面向物件分析與設計），在大腦中習慣用高層（high

level）、抽象的模型，而不是一行行具體、累贅的程式碼來進行快速、敏捷地思考和決策，是軟體架構師的一項基本功。這不是說程式碼不再重要，而是因為合格

的軟體架構師對程式碼細節、語法技巧等已經爛熟於胸，可以更加超脫、寬廣的視野思考一些比程式碼更為重要的設計。

對於職業的軟體工程師與高手們而言，軟體不僅僅是平面、具體的原始碼，軟體還是分層、立體的，具有橫向和縱向的抽象多層結構；程式設計也不僅僅是寫程式碼，還有上層更為重要和關鍵的系統分析與設計，而程式碼只不過是分析設計（抽象思考活動）的結果與體現。

而

普通碼農，由於缺乏思維訓練、設計經驗和思考能力不足，常常不習慣或不善於抽象思考，難以理解抽象的事物，而更樂於理解低層（low

level）細節和具體的事物（如程式碼），不知道原始碼之上其實還有抽象的面向物件設計模型（OOD）、分析模型（OOA）等上層建築，不知道程式碼錯誤常

常是由於自己的設計（大腦中的“設計模型”）錯誤、缺陷所導致的。許多業餘和初中級碼農不明白，自己的 Java、C# 。。。

等程式老寫不好，老出錯，老是要改，其中一個主要原因是因為他們不熟悉或不懂 OOD（包括 OO 程式設計的原則、模式和技巧）。而 OOD

不好，你寫的程式 OOP 也不可能好，所謂的精通 OO 程式設計是假的。

專業程式設計師學習程式設計，思維從具體到抽象，從低層到高層，從沉溺實

踐細節到鑽研理論方法，從關心程式碼實現到關心架構設計，是一個很自然的成長、升級過程。作為 70 後，我是從 1996

年計算機系研究生二年級開始自學的 C++、Java、設計模式，1998 年畢業後又自學的 OOAD 和 UML，當時正是 OOAD

在國外最火的年代，而 OOAD、UML、設計模式這些技術課程在國內大專院校基本普及是 2005 年以後的事吧。

軟體開發如何進行

OOAD？最佳手段當然 UML 建模。作為國際標準（ISO、OMG），UML 的一個主要用途正是作為 OOAD 的標準建模語言。如今 20

年過去了，對於一位帶領團隊負責開發 OO 軟體系統的架構師而言，在平時工作中不懂系統分析與設計的方法論，也不會 OOAD，看不懂 UML

圖，甚至連在白板上畫個規範一點的設計圖也畫不好，這些都是令人難以想象和接受的。難道作為高階程式設計師、架構師的他，只會用程式碼思考？所以我們說，不但建

模、系統分析設計是架構師的基本功，OOAD、UML 也是。

然而，15 年來中國的軟體江湖上為什麼老有一批人強烈地反對 OOAD、UML，甚至一度還成為江湖上程式猿群體的主流意識？原因是多方面的。

原因二、UML 幫你對軟體架構和設計進行抽象、全面、敏捷地分析與思考

UML

建模方法透過多種圖形（Diagram）和檢視（View）提供了多個層次、多個角度分析、觀察軟體架構的豐富手段和靈活表現形式，例如著名的“4+1

檢視”（Use Case View， Logical/Design View， Process View， Implementation

View， Deployment View）等。基於這樣的思考，軟體架構的設計才是全方位、系統化和高質量的。

（圖片來源：網路）

我

認為 UML 最大的價值，在於幫助開發者對軟體設計進行敏捷的思考（Agile thinking in

UML）。針對一個具體、複雜的軟體設計問題，程式設計高手在開始編碼之前常常善於利用各種模型、圖形與方法論在自己的大腦中進行深入思考和建模（Mind

Modeling），明確需求，評估方案的可行性和有效性，衡量各種可選方案的利弊，必要時也會利用白板、圖紙等建模工具進行設計，做到胸有成竹後才動

手，結果往往效率高、質量高而差錯和返工少。這就是專家們常說的 Quality Before Code。

而普通碼農，由於缺乏設計經驗和思維訓練，常常對一個問題的需求和方案還沒想明白就習慣性地、急匆匆地開始編碼，思維不成熟、考慮失誤的結果必然導致程式碼錯誤一大堆，改來改去還老改不對（俗稱 code and fix），因此浪費了不少時間和精力，還美其名曰“重構”。

每

天動手編碼前或在編碼過程中進行少量、必要（just enough）的 UML

建模、方案設計與思考，可以避免後期許多的折騰和浪費，這無疑是一種非常敏捷的優秀工程實踐。其實像 Scott Ambler、Craig

Larman、Martin Fowler 等敏捷大師都一直鼓勵和提倡敏捷建模（Agile Modeling）如 UML Sketch（UML

素描）。可惜在敏捷運動的前十年時間裡這並未引起大家的足夠重視，因此我把 UML 建模（包括敏捷建模、太極建模等）列為 Agile 2。0

的一個重要實踐。

原因三、UML 幫你快速、形象、牢固地記憶設計模式和方案

20

多年來，大量成熟的軟體設計最佳經驗已經被國內外專家與大師們儲存在設計模式（Design

Pattern）當中。程式設計高手與普通碼農的一大區別就在於掌握軟體設計經驗和知識的多少，而高手精通大量的軟體設計模式，不但腦儲存量大，可以信手拈

來、隨用隨取，而且往往能用得恰到好處。

設計模式中蘊涵的軟體設計經驗都是抽象的知識，它們高於程式碼，不是程式碼，所以用 UML

來表現設計模式常常是最佳方式，兩者是絕配。當有人唸到一個設計模式的名稱，如

Observer，你的腦海中是否能很快浮現出這個設計模式的具體結構，有哪幾個類或物件，它們之間的靜動態關係如何，是如何執行運轉的？為了記住一個經

典好用的設計，有了 UML 這些抽象、簡單的圖形符號，我們就沒必要再死背一行行的程式碼，而只需要輕鬆、有效地記住一個抽象的設計框架和實現重點。

程式設計高手最厭惡死記硬背，而普通碼農常常習慣、依賴於死記硬背。透過 UML 圖（如類圖、互動圖等）來分析、記憶許多設計模式和其他成熟的設計方案，是提升個人軟體設計能力的一條捷徑。有透過背程式碼來死記設計模式的嗎？這麼做是不是有點笨？

。。。

fantiny2015-07-30 22:10:21

組織程式碼能力強的，也就是大家說的會設計的人經常被人稱為高手。

掌握UML建模其實不是成為程式設計高手的一條捷徑。

掌握UML建模是高手之間高效的交流手段。

學UML是為了透過這種形式化表現方式，快速的自頂向下的瞭解別人的設計思路。

學會UML並不會自然的學會建模。學UML只是學會了一種模型的表示方法。

設計思路的文件化表現就是UML。

一切為了交流。

面向物件思考2017-05-09 07:03:11

提高程式設計能力的第一方法當然是程式設計。只是程式雖然最準確，但是隻能看到區域性，只能是在程式設計者的頭腦中形成整體的感覺。

這時就需要圖形來幫助思考，幫助開發者的把握更大的問題。

UML是國際上公認的面向物件的表示方法。可以直接拿來使用，而不必自創一種表達方式。

UML（或者其他的建模工具）不是成為程式設計高手的充分條件，但是卻是成為大師的必要條件。

最後一點：許多所謂UML的問題，實際上是UML建模者的問題。

諸葛不亮2019-04-24 23:34:18

畫的最多的是白板上的框圖（模組劃分、層次劃分、匯流排和訊息互動等）的路過，然而這些圖加起來都沒白板上的偽碼多。

至於uml？如果不是為了寫文件，誰特麼會用這鳥東西？

真信了高贊那些營銷號的忽悠，你就真的涼了。

相信我，程式設計高手思考程式碼怎麼編寫，軟體怎麼架構時，腦海中根本不會有uml這玩意——程式碼層根本不需要用它描述，腦海裡有個概念就能自然而然碼出來；架構層更不會用它描述，複雜一點的設計模式就已經是它的極限了，拿來描述更復雜的架構設計純屬吃飽了撐的。

更別說什麼OOAD架構師基本功了，我現在正在做的，基於某個IEEE標準的大型架構體系，相關的教材文件，不管中英文，我特麼就沒見過一張任何形式的uml圖——這東西我用腦圖整理下體系架構，100%縮放都可以擺滿五個螢幕，然而可以讓不懂程式碼的測試同學看懂。uml架構師，請。

舉點接地氣的例子吧。

比如說，我有一個包含20個狀態的狀態機，請問如何用uml類檢視+時序圖+泳道圖描述它的運作？狀態機可是圖狀的拓撲結構，就uml類檢視那種純靜態的，或者時序圖/泳道圖那種純線性的描述方式，怕不是要畫瘋掉？（什麼？uml狀態圖？請問和我畫個圈圈寫個s1再拉個箭頭標下條件有何區別？）

再比如，我有一套純非同步的軟體架構（比如神馬asio啦，神馬node啦，神馬qt訊號槽啦），所有元件都是基於訊息佇列事件迴圈，採用reactor/proactor式的非同步執行，並且還用了一些閉包/lambda之類的函式式黑科技來最佳化程式碼結構。uml建模，請。

亦或者，我有個底層的infrastructure級別的基礎元件，全程用的是模板技術編寫的，都沒到超程式設計地步，也就有那麼個三四層模板巢狀，類也不多就那麼七八個，請用人類看得懂的uml圖把它畫出來。

最後換個場景，我不寫cpp，我寫的是go，開發的某個服務裡，有幾千個協程，承擔十來種不同的任務，麻煩用uml講解一下它是怎麼運作的。

uml這東西，對技術人員描述能力不會強過偽碼+框框線條，對非技術人員的可讀性遠不及如完全沒規範約束的框圖，繪製的繁瑣程度至少前三，顏值更是在所有圖表裡當之無愧倒數第一。所以

和客戶交流時，我腦子有病才用uml；和開發交流時，我腦子有病才用uml。

小彩蛋：uml + ThinkPad的720p解析度42%色域tn屏，對保護眼睛有奇效哦，順帶讓你充滿歷史的厚重感，一看就是從業幾十年的老前輩，做一次企業諮詢收費大幾萬的那種（滑稽

這是我們基於外掛式開發框架的軟體開發解決方案，我只需要三頁ppt，兩三分鐘時間講解，可以讓客戶get到這個解決方案的所有優越性，然後根據客戶提問再具體切入到裡面的每一個小塊。

如果用uml，大概不是先甩客戶幾十頁ppt，講個半小時，然後給客戶端上一杯濃茶一杯咖啡提提神，送上一瓶珍視明滴眼液拯救下快瞎的眼睛，然後再進行問答環節？

就像上面的例子，框圖畫得漂亮至少還能當個

ppt戰士

，用華麗的ppt和技術方案把客戶忽悠到手。uml畫得再細緻，除了用來寫又長又臭的設計說明，還有毛用？

哦，難道你會在會議上指著ppt對甲方爸爸說，“這裡有個A類，它繼承自I介面，包含有bcd方法efg屬性…這裡是A類和B類之間訊息傳遞的時序圖…這裡是ABC三個模組協同合作的泳道圖…這裡是ABC泳道圖第幾個環節裡的狀態轉換圖…”，那下次談客戶時記得叫上我，我不介意做接盤俠。

亦或者用這個手法在開發團隊內部溝通設計？需要手把手用uml教怎麼寫類以及怎麼組織類之間的互動的菜雞同事，你設計再好又有啥用？有這功夫，我選擇給同事培訓設計模式，然後拉一下框圖，標註一下哪些環節可以用哪種模式來做，ok擼起袖子開幹吧。

蝸牛網際網路2021-01-15 00:18:01

首先你要了解 UML 是個什麼，它為什麼出現，它的適用場景以及它怎麼使用，才能比較清晰它在你成為程式設計之路上的重要作用。以下從這幾個角度講講 UML。

一、前言

談到面向物件技術的分析和設計，自然就離不開 UML。對於 UML 這個概念，很多程式設計師朋友耳熟能詳，也有在用，但在工作中，一些朋友其實並不擅長使用 UML 甚至對 UML 這個東西模稜兩可，也包括我自己。因此我希望可以結合自己的經驗和實踐，寫一篇 UML 的入門文章，幫助做面向物件的程式設計師朋友能更好的利用它，從而順利完成自己的程式設計設計工作。

以下是本文大綱。

二、從一個示例開始

先舉個現實世界的例子。我們上大學的時候，作為學生，每人都有一張學生證，會歸屬到一個班級，上學時可能會用到腳踏車。很多同學還會考駕照，挑放假時間練車，車可能是轎車也可能是皮卡。

如果想透過線上的方式記錄以上的資訊和行為，在軟體世界中如何表達呢？

相信很多朋友的操作是，找到這段話裡的主語和賓語，也就找到了這個例子中涉及的角色，然後透過動詞來判斷各個角色之間的關係和能力，最後用程式碼的方式來表達，產出可執行的程式。

像下圖這樣，識別出關鍵的實體和它們之間的關係。

用軟體工程的方式，解決現實中的問題，是資訊時代最明顯的特點，這讓我們的生活和工作變得更加便利。

但現實世界錯綜複雜，靈活多變，每個人的理解可能會有不同，從現實世界到軟體世界的對映，就變得困難重重，一團亂麻。

如何讓現實世界到軟體世界對映變的簡單容易，這就是 UML 要解決的問題。

三、什麼是 UML？

UML 全稱是

Unified Modeling Language

（統一建模語言），它以

圖形的方式

來描述軟體的概念。

3。1 為什麼稱為語言

先說語言，為什麼稱為語言？

名稱的落腳點是語言。既然是語言，那麼它就會

具備語言的特性

，比如結構上它由詞彙和語法構成，功能上它能解決溝通問題。

你熟知的語言裡比較多的應該是漢語和英語，如果從事軟體行業，C 語言和 Java 語言你應該也不會陌生。英語和 Java 語言明顯都是語言，卻常常不被放在一起討論，為什麼？因為它們是不同維度的語言。英語是

解決現實世界中人與人之間溝通問題

的人類語言，Java 是

解決軟體世界中程式設計師與計算機之間溝通問題

的計算機語言。

人類語言本質上是

事實和觀點的表達

，計算機語言本質上是

0 和 1 的表達

。前者的表達形式是難以確定的，而且可能會產生歧義，所以才會有「被誤解是表達者的宿命」這樣的觀點， 但後者就是確定性無歧義的 0 1 表達。

這麼看來，UML 的目標是

透過一定結構的表達，來解決現實世界到軟體世界的溝通問題

。

3。2 什麼是建模

再說建模，模是什麼，需要怎麼建？

建模簡單講，是指

透過抽象的方式解決某個領域的問題

。各個抽象角度共同組成了一個問題領域。

對於傳統模型而言，建造它是為了證明這個問題領域下某件事物能否工作。當然它有前提，即建造模型的成本遠遠低於建造實物的成本。比如造飛機或造高樓。

對於軟體模型而言，建造它是為了與他人溝通，也為了儲存這個問題領域下軟體設計的最終成果。當然它也有前提，就是模型比程式碼更說明問題。

比如購物這個問題，甲可以在淘寶上買衣服，乙可以在亞馬遜上買書，丙可以在京東上買手機。

誰買東西？是甲、乙和丙，他們都能抽象成人。

買什麼東西？有衣服、書和手機，它們都能抽象成貨。

在哪裡買？在淘寶，亞馬遜和京東，它們都能抽象成場。

整體抽象一下就是人到場裡買貨。所以購物這個場景所抽象出來的人貨場，就用來解決零售領域的問題。當然還可能會有些規則，比如成為註冊會員才能發生交易。

我們會發現，

一個特定的事件（比如購物）裡，會有特定的人的行為（比如甲乙丙要上電商網站），會有特定的物（比如貨），有特定的規則（比如註冊會員）

，共同完成購物這件事。

特定的事 = 特定的人的行為 + 特定的物 + 特定的規則

在人貨場這個抽象角度裡，就會涉及到很多特定的事，包括會員註冊，會員下單，會員支付，商家發貨，快遞公司郵寄等等。

模簡單講，就是

人、事、物和規則

。

人是一切的中心，人要做事，做事就會使用一些物併產生另一些物，同時做事需要遵循一定的規則。

人驅動系統，事體現過程，物記錄結果，規則是控制

。

建立模型的關鍵就是

弄明白有什麼人，什麼人做什麼事，什麼事產生什麼物，中間有什麼規則，再把人、事、物之間的關係定義出來

，一個模型也就基本成型了。

3。3 統一的意義在哪

統一的普遍意義是

形成標準

。所謂標準，就是

所有人都明白的表述，所有人都遵從的格式

。標準可以

讓資訊在人群中無障礙地流通

，即使這些資訊來自不同地域、不同文化、不同社會或不同組織。

比如美元作為國際統一使用的貨幣方便了全球的經濟貿易，我們國家普及普通話方便了不同地區的交流溝通。

在軟體世界，任何一種元件化開發模式背後都有一個標準在規範和指導，比如 Java 的 JSR 標準。

有了標準，程式設計就容易元件化，協作效率也會提升很多

。對 UML 來說，這就是統一的意義。

四、為什麼需要 UML

一個軟體專案要經歷

業務調研、立項、需求採集、架構設計、編碼開發和測試驗證

等多個環節。

每個環節可能角色並不相同，

同樣的文件同樣的話語越向後傳遞就越容易失真

。因此就容易出現最終交付的產品不是客戶真正想要的這種情況。

如何避免角色間資訊傳遞的失真，保證資訊能被準確的傳達和準確的理解？一種好的辦法就是

大家使用標準化的語言。

統一建模語言（UML）就試圖用標準化的語言來覆蓋整個軟體過程，讓不同團隊不同角色可以用相同的語言順暢的溝通。

在資訊傳播方面，圖形相對於文字，人腦的接受能力顯然更強。因此，

UML 採用了「視覺化」的圖形方式來定義語言。

五、UML 的適用場景

UML 既可以描述某個問題領域，也可以表達構思中的軟體設計，還可以描述已經完成的軟體實現。

它適用於面向物件分析設計的整個過程。這個過程可以分為三個階段，如下圖。

第一個階段是

透過建模將現實世界轉為業務模型

。業務模型真實映射了參與者（業務活動的驅動者）在現實世界的行為。

從圖裡可以看到，現實世界對映到業務模型後，是使用

參與者

和

用例

這兩個 UML 的核心元素表達的。參與者作為一個特定事件的驅動者，用例則描述了這個驅動者的業務目標。文章後邊也會提到這兩個元素。

第二個階段是

對業務模型概念化，建立適合計算機理解和實現的模型，也就是概念模型

，或者叫分析模型。分析模型

向上映射了原始需求

，向下

為計算機實現規定了一種高層次的抽象

，是一種過渡模型。

現實世界千差萬別的業務，都用 邊界、控制和實體這幾個核心元素來描述，同時也引入了 包、元件 這些與現實世界毫不相干的概念做包裝。

第三個階段是

對概念模型例項化，得到相對詳細的設計模型。

在設計模型中，概念模型中的邊界類可以被轉化為操作介面或者系統介面；控制類可以被轉化為計算程式或控制程式，例如工作流、演算法體等；實體類可以轉化為資料庫表、XML 文件或者其他帶有持久化特徵的類。

同樣的概念模型會因為選擇不同而得到不同的設計模型

。比如技術選型上使用不同的程式語言，不同的中介軟體就會得到不同的設計。

為什麼需要這一道轉換呢？

因為“邊界”、“控制”、“實體”這些物件化的概念，雖然是計算機可以理解的，但它並不是真正的物件例項，也就是說它們並不是可執行程式碼，概念模型只是紙上談兵。真正的物件世界行為是由 Java 類、C++ 類、JSP 等這些可執行程式碼構成的。

換句話說，

設計模型是概念模型在特定環境和條件下的例項化

，例項化後的物件行為執行了概念模型描述的那些資訊。

以下是面向物件分析設計的完整過程，它表達了現實世界是怎麼透過 UML 對映到物件世界的。

六、UML 的組成結構

前面花了比較大的篇幅分析了 UML 的定位和適用場景，目的是幫助讀者建立對 UML 整體系統性的認知，而不是過早的陷入 UML 的使用細節裡。我們要應用一項技術或工具，不能單純的因為它的酷炫或者說業界都在用所以我們要用，而應該結合自己的使用場景以及技術或工具的特點，來確認這項技術或工具究竟是不是我們需要的。

在讀者瞭解 UML 在面向物件分析設計領域優秀的特性之後，我們再來看看 UML 的一些細節。

凡是語言，都會存在基本詞彙和語法。

那麼對應到 UML 裡，基本詞彙就是核心元素，語法就是核心檢視。

UML 的組成結構如下圖：

6。1 核心元素

我們先介紹核心元素，下圖是大綱。

6。1。1 版型

版型：也稱「型別」或「構造型」。是對 UML 元素基礎定義的擴充套件，在元素基礎定義的基礎上賦予特別的含義，使得這個元素適用於特定的場合。

比如，我們前邊提到的「邊界類」、「實體類」、「控制類」都是類的版型。

6。1。2 參與者

參與者定位

：事件的第一驅動者，也是系統的服務方。比如你在電商網站購物，你就是參與者。

6。1。3 用例

用例定位

：系統執行的一系列操作，並生成參與者可以觀察的值。比如你在電商網站交易，會生成線上訂單，使用者下單就是一個用例。

用例版型：

業務用例：

用於需求階段業務領域建模

。與計算機系統建模無關，比如下單可以不依賴線上服務，而只是線下籤署協議。業務建模的目標是讓需求人員和客戶能夠達成共識。

業務用例實現：

業務用例的一種實現方式

，一個業務用例可以有多種實現方式。比如下單後的支付，可以用現金，也可以銀行卡轉賬，還可以第三方支付。

概念用例：

用於獲取業務模型中的關鍵概念，分析出核心業務結構

。業務架構就是概念建模階段產生，同時為系統建模階段提供重要指導。比如使用者下單這個用例，可以從實現過程中獲得一些核心業務，並把它們展現出來。

系統用例：

用於定義系統範圍、獲取功能性需求

。也就是我們常掛在嘴邊的用例。像業務用例中提到的線下籤約的方式，就不會納入到系統用例中，但如果是電子簽約的話，就可以成為系統用例了。

系統用例實現：

系統用例的一種實現方式

，一個系統用例可以有多種實現方式。比如下單後的支付，可以接入微信支付介面，也可以接入支付寶支付介面。

你會發現，同是

用例的版型，業務用例與系統用例的區別就在於

業務用例是客戶業務視角，系統用例是系統視角。

6。1。4 邊界

邊界定位

：用於業務建模和系統建模階段的分析，保證

分析粒度在一定的範圍內

，不會擴散。

比如一個電商網站按領域職責作為邊界，會有店鋪域、商品域、會員域、交易域、支付域和營銷域等。各域只負責域內的事情，就能夠減少混亂緊耦合的局面。

一個好的分析和設計如同一筐帶殼的雞蛋，清清爽爽；一個差的設計如同一堆打碎了殼的雞蛋，粘粘糊糊。殼，是好壞的關鍵。

6。1。5 業務實體

業務實體定位

：它代表

參與者執行業務用例時所處理或使用的事物

，特別用於在

業務建模階段

建立領域模型。業務實體是類（class）的一種版型。

業務實體的結構

：包含屬性和方法。屬性用來儲存業務實體特徵，方法用來訪問業務實體。比如一臺電視，把它看成一個業務實體的話，它的屬性有執行狀態和音量，它的方法就是遙控器，我們可以開、關、調聲音，但是我們不可以試圖讓它飛起來——因為它沒有這樣的方法。

6。1。6 包

包定位

：容納併為其他 UML 元素分類。比如 Java 後端經常會提供 jar 包給接入方使用。

6。1。7 分析類

分析類定位

：用於代表系統中主要的職責簇，由此產生系統的設計類和子系統。

邊界類：用於

對系統外部環境和內部運作之間的互動

進行建模。比如現實世界的窗戶，計算機世界的網頁。

控制類：用於

對用例特有的控制行為

進行建模。比如顯示邏輯和業務邏輯透過控制層分離的 MVC 架構。

實體類：用於

對需要儲存的資訊和相關行為

進行建模。源於業務模型中的

業務實體

。

分析類的抽象層次較高，比設計和實現要穩定很多，因此方便維護，也更容易獲得一個穩定架構來指導整個軟體的開發。

6。1。8 設計類

設計類定位

：是系統實施中一個或多個物件的抽象，由此

對映到實現程式碼

，依賴於實施語言。

設計類結構

：

型別：對物件某一方面特徵的歸納和抽象。對映到編碼中的 class。

屬性：物件特徵。對映到編碼中的 field。

方法：訪問物件屬性的唯一途徑。對映到編碼中的 method。

6。1。9 關係

關係定位

：抽象出

物件之間的聯絡

，讓物件構成某個特定的結構。

關係分為以下幾種：

關聯（association）

關係：是一種

擁有

的關係，即一個類知道另一個類的屬性和方法；比如老師與學生可以是雙向的，也可以是單向的。雙向的關聯可以有兩個箭頭或者沒有箭頭，單向的關聯有一個箭頭。

箭頭和連線：

帶普通箭頭的實心線

，指向被擁有者。

適用場景：類圖。

依賴（dependency）

關係：是一種

使用

的關係，即一個類的實現需要另一個類的協助，是一種弱關係，隨執行場景變化。比如削蘋果時，人依賴於刀，脫離了這個場景，依賴關係就不存在了。

箭頭和連線：

帶箭頭的虛線

，指向被使用者。

適用場景：類圖。

泛化（generalization）

關係：是一種

繼承

的關係，比如貓是動物的一種。

箭頭和連線：

帶三角的實線

，箭頭指向父類。

適用場景：類圖。

實現（realization）

關係：是一種

實現

的關係，比如用例和用例實現的關係，介面與實現類的關係。

箭頭和連線：

帶三角的虛線

，箭頭指向用例實現或介面類。

適用場景：用例圖，類圖。

聚合（aggregation）

關係：是

整體與部分

的關係，且

部分可以離開整體而單獨存在

。生命週期各自獨立。如車和輪胎是聚合關係，輪胎離開車仍然可以存在。

箭頭和連線：

帶空心菱形的實線

，菱形指向整體。

適用場景：類圖。

組合（composition）

關係：是

整體與部分

的關係，但

部分不能離開整體而單獨存在

。同生同滅。如公司和部門是組合關係，沒有公司就不存在部門。

箭頭和連線：帶實心（黑色實心：要死一起死，良心是黑的）菱形的實線，菱形指向整體。

適用場景：類圖。

關聯關係和依賴關係的區別

：

關聯關係是靜態天然的聯絡，依賴關係是動態臨時的聯絡。

此外還有隻用於用例中的關係：

擴充套件（extends）

關係：

用於在用例模型

中說明向基本用例中的某個擴充套件點插入擴充套件用例。

箭頭和連線：帶箭頭的虛線加版型

<>

。

特點：用例可選。

包含（include）

關係：

用於在用例模型中

說明在執行基本用例的用例例項過程中插入的行為段。

箭頭和連線：帶箭頭的虛線加版型

<>

。

特點：用例必需。

6。1。10 元件

元件定位

：實現特定功能的邏輯程式碼模組。比如分散式應用架構下，將業務目標拆成多個功能，每個功能作為元件獨立部署。這樣這些元件也能被其他場景複用。

6。1。11 節點

節點定位

：表示應用程式的部署單元。比如分散式應用的環境中，伺服器或裝置會有很多，就需要透過節點來體現物理部署的情況。

6。2 核心檢視

前面我們介紹了 UML 的核心元素，這些元素分別應用於面對物件分析設計的各個階段，正是它們之間的相互組合，才形成了 UML 裡的各種檢視，最終指導軟體設計。

接下來講講核心視圖裡的結構檢視和行為檢視，下圖是大綱。

6。2。1 結構檢視

結構檢視也稱為

靜態檢視

。靜態檢視就是

表達靜態事物

的。它只描述

事物的靜態結構

，而不描述其動態行為。這裡簡要介紹的靜態檢視包括

用例圖，物件圖，類圖，元件圖，包圖和部署圖

。

6。2。1。1 用例圖

用例圖包含

參與者、用例和關係

這三種核心元素，不同的視角可以得到不同的用例檢視，它展現了系統的功能性需求。

所謂不同的視角，可以對應面向物件分析設計的三階段。

建立業務模型階段，產出

業務用例檢視

。

建立概念模型階段，產出

概念用例檢視

。

建立設計模型階段，產出

系統用例檢視

。

就借閱圖書的用例而言，業務用例檢視如下，它是完全從業務角度出發，和計算機系統無關。

而我們在業務用例分析的過程中，可以分解出一些關鍵的概念用例，並建立它們之間的關係，如下圖（bu 表示業務用例，cu 表示概念用例）。

我們對業務用例進行分析以後，就可以繪製系統用例檢視。但不是所有的業務用例都有系統用例對應，比如檢查借閱證可能是手工工作，就不需要納入系統建設範圍。

下圖是借閱圖書的系統用例檢視。

6。2。1。2 類圖

類圖用於

展示系統中的類及其相互之間的關係。

類圖建模常用的方式是從

概念層，到說明層，最後到實現層

這麼一個抽象層次逐步降低和細化的過程。

概念層類圖位於業務建模階段

，這個階段採用

業務實體

這個核心元素來表示。

下圖是網上購物的業務實體圖。

網上購物主要由商品、訂單、支付賬戶這幾個關鍵類構成，這幾個類的互動能夠完成網上購物這個業務目標。

說明層類圖位於概念建模階段

，這個階段採用

分析類

這個核心元素來表示。

下圖展示了網上購物的說明層類圖，這個類圖表達了從計算機的視角來說，網上購物這個業務目標是由哪些類來完成的，這些類的介面保證了這個業務目標的達成。

實現層類圖位於設計建模階段

，這個階段採用

設計類

這個核心元素來表示。

到了這一層，類圖可視作虛擬碼，因此，在這個層次上，類必須明確採用哪種實現語言、什麼設計模式、什麼通訊標準、遵循什麼規範等。

下圖展示了查詢商品功能的類圖。可以看到，到了實現層類圖，類描述和類關係已經是虛擬碼級別了。

由此可見，在軟體生命週期的不同階段，類圖也有三種不同的表達，他們分別是

概念層類圖，說明層類圖和實現層類圖

。

很多朋友在建模的時候只會用到實現層類圖，並非他們對問題領域足夠了解，而是不清楚類圖也分了這麼三層。

6。2。1。3 物件圖

物件圖是類圖的例項，標識和類圖基本相同。由於物件存在生命週期，物件圖只能在系統某一時間段存在，因此物件圖可以被想象成正在執行的系統在某一時刻的快照。

比如一個正在執行的列車，如果用物件圖來描述，某個時間點你會發現以下靜態圖片：

當前的執行狀態（執行中或停車中）

當前的乘客數量。（如果捕捉在不同的時間，該值會變化）

6。2。1。4 包圖

在實際的專案中，建模過程獲得的元素可能是非常多的，如果將這些元素的關係都繪製出來，看上去就會特別亂，特別複雜，也難以識別。

那為了更好的理解和管理這些建模元素，我們就需要

有規律的對元素進行組織

。包圖就起到了這麼一個作用，透過包這個容器，可以

從大到小、從粗到細地將建模元素組織起來

，便於我們的

分析，交流和細化

。

下圖是網上購物的領域包圖，它表達了關鍵業務領域及其依賴關係。

下圖展示了查詢商品功能的類層次，它表達了實現類位於哪個層次的軟體架構的觀點。

6。2。1。5 元件圖

當有些包能夠

被多個場景重複使用

，那這個包就可以認為有著特定的功能，能夠完成特定的目標。

這種情況下，包就可以定義為元件，

元件是一種特殊的包，既起到了普通包組織和容納的作用，又能完成特定的功能

。

比如模組（登入模組），類庫（Java Guava 包）。

下圖可以表達元件實現的過程，透過第三方軟體或者面向物件分析設計過程中產生的各種包，可以定義元件。

元件可以按功能分為以下幾類：模組、子系統、庫、可執行檔案和程式包等等。

6。2。1。6 部署圖

部署圖描述了

物理上系統執行時的結構

，包括系統中

硬體的分佈以及軟體部署到硬體上的具體方式

。

部署圖用於

設計建模階段

，採用

節點和關係

兩種核心元素來繪製。常用於分散式應用環境和多裝置應用環境。

上圖是一個簡單的部署圖，表達了客戶端比如瀏覽器這個節點，會請求到 Web 伺服器節點，最後透過資料庫伺服器節點返回資料。如果涉及分散式環境，就要考慮多個 Web Server，多個 Database Server，甚至考慮多機房，異地等物理層面的部署方式。

6。2。2 行為檢視

結構檢視介紹完，我們講講行為檢視。

行為檢視也稱為

動態檢視

。動態檢視就是描述

事物動態行為

的。動態檢視不能獨立存在，它必須

基於一個靜態檢視或者 UML 元素

，說明在靜態檢視規定的事物結構下它們的

動態行為。

這裡簡要介紹的動態檢視包括狀態圖、活動圖、時序圖和協作圖。

6。2。2。1 狀態圖

狀態圖

也稱狀態機

，它

描述了一個物件的生命週期

，你可以把它理解成一臺執行中的機器，這臺機器

負責這個物件在固定幾個狀態間的流轉。

這個物件可以是

業務實體物件

，也可以是

分析類物件

，還可以是

設計類物件

。也就是說，在面向物件分析設計的

三個階段

（業務建模，概念建模，設計建模），都可以用狀態圖來表達。

下圖是一個產品的生命週期狀態圖。綠色部分是狀態圖相關的元素，紅色部分是元素的解釋。

從圖中，我們可以看到，狀態圖有以下關鍵元素：

初始狀態：它是狀態機的

起始位置

，不需要事件的觸發。用實心圓圈表示。

狀態：狀態是物件

執行某項活動或者等待某個事件時的條件

。比如要想執行產品入庫動作，產品得是未入庫的狀態，如果想銷售某個產品，產品得是入庫的狀態。

轉移：轉移是

兩個狀態之間的關係

，它表示當發生指定事件並且滿足指定條件時，第一個狀態中的物件將執行某些操作並進入第二個狀態。比如產品入庫這個動作，就將產品的狀態從未入庫轉移到了已入庫。

事件：事件是一個

特定的動作或行為

，有時候也包括系統時鐘之類的定時器。如果條件滿足，事件的發生將觸發一個轉移。比如產品銷售這個動作，出發產品從已入庫狀態轉移至已銷售狀態。

條件：條件是一個

布林表示式

，當事件發生時將檢查這個表示式的值。條件求值結果可能決定轉移的分支，或者拒絕轉移。條件有可能引用當前狀態。比如產品合不合格這個布林判斷，決定了產品是可被銷售，還是不可被銷售。

最終狀態：最終狀態表示

狀態機執行結束

，或者物件生命週期結束。用帶環的實心圓圈表示。

6。2。2。2 活動圖

活動圖描述了為了

完成某一個目標需要做的活動

以及這些

活動的執行順序

。

UML 中有兩個層面的活動圖，一種是

用例活動圖

，它用於描述

用例場景

，常用於業務建模階段，另一種是

物件活動圖

，用於描述

物件互動

，常用於設計建模階段。

下圖是一個登機手續辦理的用例活動圖。綠色部分是活動圖相關的元素，紅色部分是元素的解釋。

從圖中，我們可以看到，活動圖有以下幾個關鍵元素：

起始點：起始點

標記業務流程的開始

。一個活動圖僅有一個。用實心圓圈表示。

活動：活動是業務流程中的一個

執行單元

。比如辦理登機手續需要出示機票和身份證這樣的動作。

判斷：判斷

根據某個條件進行決策

，執行不同的流程分支。比如身份核對決定了你能否繼續辦理登機手續。

基本流：基本流表示

最主要、最頻繁使用的

、預設的業務流程分支。比如身份核對的正常分支。

支流：支流是進行判斷後走進的

業務流程分支

。比如圖中無行李分支。

異常流：異常流表示

非正常的、不是業務目標期待的、容錯性的、處理意外情況

的業務流程分支。比如身份證核對錯誤。

同步：同步分為

同步起始和同步匯合

。

同步起始表示從它

開始多個支流並行執行

。比如托執行李的處理和登機牌的列印操作，可以並行。

同步匯合表示

多個支流同時到達後再執行後續活動

。

結束點：結束點表示

業務流程的終止

。一個或多個。

用例活動圖常常是從業務的角度上，分析要完成某個目標，要執行哪些活動。如果在系統設計的角度上，要表達完成目標需要的活動，就需要用到物件活動圖。

比如根據查詢商品的物件互動過程，就能繪製出以下的物件活動圖。

雖然 UML 允許用活動圖繪製物件互動，但實際工作中，

我從來沒用過

。因為 UML 有其他更好的工具來繪製物件互動圖，比如接下來要講的時序圖。

6。2。2。3 時序圖

時序圖用於描述按

時間順序排列的物件之間的互動模式

。

前面類圖那一節有提過類有三個層次的觀點：

概念層、說明層和實現層

，分別對應於面向物件分析設計的

業務建模階段、概念建模階段和設計建模階段

，相應的，也可以在這三個層次上分別對

業務實體物件、分析類物件和設計類物件

繪製

業務模型時序圖、概念模型時序圖和設計模型時序圖

。

接下來介紹三種時序圖。

業務模型時序圖用於為

領域模型中的業務實體互動建模

，目標是

實現業務用例

。

上一節提到的活動圖，可以幫助我們發現業務實體，活動圖也可以很輕易的轉換成時序圖，下圖是網上購買商品的業務模型時序圖。

時序圖中會涉及一些 UML 元素，這裡列舉常用的幾個：

物件：表示

參與互動的物件

。每個物件都有一條生命週期線，物件被啟用時，生命週期線上會出現一個長條（會話），表示物件的存在。

生命週期線：表示

物件的存在

。當物件被啟用時，生命週期線上出現會話，表示物件參與了這個會話。

訊息：表示

物件間互動所發生的動作

。由一個物件的生命週期線指向另一個物件的生命週期線。常見的訊息型別有以下幾種：

簡單訊息：

向右的實線箭頭

，這種最為常用。

返回訊息：

源訊息的返回體，並非新訊息

。用向左的單向虛線箭頭表示。

一般不需要為每個源訊息都繪製返回訊息

，一方面源訊息預設情況下都有返回訊息，另一方面過多的返回訊息會讓圖變得更復雜。

同步訊息：表示

發出訊息的物件將停止所有後續動作

，一直等到接收訊息方響應。用向右帶×的單向實線箭頭表示。同步訊息將阻塞源訊息所有行為。通常程式之間的方法呼叫都是同步訊息。

非同步訊息：表示源訊息發出訊息後不等待響應，而可以繼續執行其他操作。

用向右的單向上箭頭表示

。非同步訊息一般需要訊息中介軟體的支援，如 MQ 等。

會話：表示

一次互動

，在會話過程中

所有物件共享一個上下文環境

。例如操作上下文。

銷燬：表示

生命週期的終止

。繪製在生命週期線的末端，一般沒有必要強調。

業務模型時序圖是

業務建模階段的產物

，它展現了業務的實際需求，因此使用的

描述語言應當採用業務術語

。

進入概念建模階段，可以採用

分析類繪製概念模型時序圖

。和業務模型時序圖相比，同樣是展現業務需求，不同點在於

分析類代表了系統原型

，所以這個階段的時序圖已經帶有了計算機層面的理解。

因此，概念模型時序圖

既保留了實際業務需求

，又得到了

計算機實現的基本理念

。如下圖所示。

可以看到，在概念模型時序圖裡，相對於業務模型時序圖，我們的表達增加了安全認證和商品目錄。這是因為我們實際在做登入這個功能時，我們的軟體系統需要關心身份核驗。我們在獲取商品時，為了避免雜亂需要對其進行分類。

另外，我們的業務實體轉為分析類進行表達，

網站作為邊界類

，用於隔離使用者操作和系統行為。

安全認證作為控制類

，用於決定是否能成功登入網站。

商品目錄和商品作為實體類

，用於表達使用者實際想看到或者操作的實體資訊。

分析類展示出來的已經是系統實現的原型，進入設計建模階段，我們做的工作就是要

選擇合適的實現方式來實現這個原型

。

設計建模階段，我們採用設計模型時序圖來實現概念模型中的互動。

設計模型時序圖使用設計類作為物件繪製，也是我們日常開發設計中最為常用的動態檢視。以下是商品查詢的設計模型時序圖。

可以看到，在設計模型時序圖裡，

訊息會細緻到方法級別

。因為在這個階段，相關的技術選型，比如程式語言，互動協議，中介軟體等已經比較明確了。

時序圖除了在建模的三個階段使用外，當你需要

表達物件的互動

，或者想

分析物件的職責和介面

時，都可以使用時序圖。

6。2。2。4 協作圖

協作圖和時序圖一樣，也是描述物件之間的互動模式，不同的是，時序圖在意的是

物件互動的執行順序

，而協作圖在意的是

物件間的結構關係。

因此，時序圖適用於

獲得對呼叫過程的理解

，而協作圖適用於

獲得對物件結構的理解。

協作圖可以和時序圖互相轉換，對應時序圖的三種表達方式，協作圖也分為

業務模型協作圖

，

概念模型協作圖

和

設計模型時序圖

。本文只介紹業務模型協作圖，另外兩種協作圖可以由相應的時序圖推導，這裡就不贅述了。

業務模型協作圖同樣採用業務實體來繪製，目標也是實現用例場景。下圖是網上購買商品的業務模型協作圖。

可以看到，協作圖和時序圖相比，物件間的結構一目瞭然，很容易

知道哪些訊息會影響哪些物件或者哪些物件需要提供哪些介面

。但在執行順序的表達上就很弱，必須依賴訊息文本里的數字。

以下是協作圖常用的 UML 元素：

物件：表示

參與協作的物件

。

物件關聯：用於

連線兩個物件

，表示二者的關聯。這種關聯是臨時的，只在本次互動中有效。

訊息：和時序圖中的訊息定義一致。

訊息序號：表明

訊息傳遞的先後順序

。

6。2。3 小結

本節介紹了 UML 的核心檢視，我們再看下核心檢視的大綱。

核心檢視分靜態檢視和動態檢視。靜態檢視

表達事物的結構性觀點

，動態檢視

表達事物的行為性觀點

。

一個好的建模，結構性和行為性都不可或缺，既要說明

該事物長什麼樣子

，又要說明

該事物應該怎麼用

。

七、總結

本文從一個示例開始，引入了 UML 的概念，介紹了

什麼是 UML，為什麼要用 UML以及什麼時候用 UML

。我們瞭解一個事物，

知其然也要知其所以然

。

然後介紹了 UML 的組成結構，從元素和檢視的角度出發，講解了繪製圖形的方法和相關概念。文中也給出了很多我親手繪製的樣例檢視，如有錯誤之處，還望讀者指摘。

紙上得來終覺淺，絕知此事要躬行

。知道和做到總有一段距離，重在實踐。

希望這篇文章對從事面向物件程式設計的讀者朋友能夠有所啟發，歡迎和我一起交流，也歡迎

轉發

給有需要的朋友。

（完）

萬字多圖 | UML 入門指南 · 語雀