UML圖繪製的注意點和實例分析

先百度一下，Unified Modeling Language (UML)又稱統一建模語言或標準建模語言，是始於1997年一個OMG標準，它是一個支持模型化和軟體系統開發的圖形化語言，為軟體開發的所有階段提供模型化和可視化支持，包括由需求分析到規格，到構造和配置。

UML可以看做用於系統設計階段給開發做參考的一種方式，其很多圖需要用到面向對象程序的思維。畫UML圖是產品經理的必備技能之一。

廢話不多說，本文介紹一下最常見的幾個UML圖：類圖、用例圖、狀態圖、序列圖、活動圖，以及一個並不屬於UML，但也有很大作用的數據流圖。每張圖詳細介紹一下畫法、注意點和具體案例。相關的概念、元素等則簡單介紹。

一、類圖

類圖是UML圖中看起來最複雜的一個圖。它與資料庫和面向對象編程的聯繫比較緊密。沒學過面向對象或者資料庫的同學剛開始畫類圖可能比較吃力。

一句話介紹一下類：類即相同屬性、操作、關係和語義的對象的描述。類的組成：屬性、操作。

類圖描述系統中類的靜態結構。它的作用是定義系統中的類, 表示類之間的關係(關聯, 依賴, 聚合等),描述類的內部結構(屬性, 方法等)。一個類長什麼樣看下圖。

類圖有涉及到面向對象的知識，在此不一一敘述。圖中有些看不懂的名詞請自行百度。

類之間通過關係連接起來。類圖中的關係很多，在此介紹最常見的關聯關係。關聯關係是一種擁有的關係，它使一個類知道另一個類的屬性和方法。關聯關係的類通過箭頭連接起來。

下面分析具體案例：公司圖書管理系統，包括借書、還書、申請買書的操作。借書過程：員工發起借書申請，由行政人員去圖書館拿書給員工。還書買書類似。後面的圖也是用這個案例。

這幅圖就是借書系統的類圖。要簡化的話可以將可見性符號和屬性的類型省略。圖中的空心三角形應該為箭頭。

員工、書、訂單三個類比較容易理解，代表了三個抽象的實體。借書類則是員工和書之間借書行為的一個抽象，連接了員工和書，記錄了借書這個狀態中的一些信息，以及借還書操作。買書同理。

列幾條類圖繪製的要點。

類的操作是針對類自身的操作，而不是它去操作人家。比如書這個類有上架下架的操作，是書自己被上架下架，不能因為上架下架是管理員的動作而把它放在管理員的操作裡。兩個相關聯的類，需要在關聯的類中加上被關聯類的ID，並且箭頭指向被關聯類。可以理解為數據表中的外鍵。比如借書和書，借書需要用到書的信息，因此借書類需包含書的ID，箭頭指向書。由於業務複雜性，一個顯示中的實體可能會被分為多個類，這是很正常的，類不是越少越好。類的設計取決於怎樣讓後臺程序的操作更加簡單。比如單看邏輯，借書類可以不存在，它的信息可以放在書這個類裡。然而借還書的書的上架下架完全不是一回事，借書類對借書的操作更加方便，不需要去重複改動書這個類中的內容。此外，如果書和借書是1對多的關係，那就必須分為兩個類。類圖中的規範問題，比如不同關係需要不同的箭頭（本文只介紹了1種關係），可見性符號等。二、用例圖

用例圖是最常見的一種圖。用例圖概括了用例中角色和系統之間的關係，描述了系統功能需求，角色和系統的交互以及系統的反應。

用例圖有參與者、用例、關係組成。參與者就是系統中的用戶身份。用例是系統中的一個功能的概括。關係是參與者或者與用例的聯繫。其中關係可以分為關聯、泛化、包含和擴展4種關係。關係的運用是用例圖最難的部分。4種關係的說明：

關聯是參與者和用例之間的關係，用箭頭；

泛化是參與者與用例或用例之間的關係，意思是特殊化。比如吃飯和吃晚飯。兩者的本質是一樣的。符號用空心的三角形。箭頭為被指向。包含是用例之間的關係，意思是一個用例包含另一個子用例。子用例是必須存在的，沒有子用例則功能不能完成。符號在箭頭的線上加<<include>>。箭頭為去指向。擴展也是用例之間的關係，意思是一個用例可以擴展出一個子用例。與包含不同的是，這個子用例是不一定要存在的，沒有也一樣能完成功能。符號在箭頭線上加<<extend>>。箭頭為被指向。

還是上面那個圖書管理的案例

行政人員和員工是參與者，中間的這些是用例。這幅圖用例之間大部分都是包含關係，比如借書包括申請、查找、借閱這三個子用例，都是必須的。而圖書續借不是必須的，因此只是擴展的用例。批量購書是購書的一個特例，和購書本質是相同的，因此作為泛化的關係。

繪製的注意點：

用例之間的關係，尤其是包含和泛化的區別，可以這樣區分，試著把包含的用例讓泛化的用例來包含後，看看是不是同樣成立箭頭指向，泛化和擴展的指向和包含是反的用例的表達是動詞+名詞的形式，只有一個動作或者名詞的不是用例。比如所有書籍，是否可借等表述就不是用例。三、狀態圖

狀態圖是UML中相對比較簡單的一張圖，用得也沒前兩種圖多。狀態圖是描述一個實體基於事件反應的動態行為，顯示了該實體所有可能的狀態，以及事件發生時狀態的轉移條件。

總結一句話，狀態圖就是把類的狀態的改變連城一張圖。狀態圖的元素包括狀態、轉移和動作。元素的形式如下圖所示，黑點分別為起始點，矩形為狀態，箭頭上時狀態改變的動作和事件。

狀態圖可以看做是類圖的補充，因為狀態本身就是類的狀態。狀態圖的繪製過程很簡單，只要先把類的狀態羅列，然後按順序連起來，最後寫上動作或條件即可。上圖中連接線上依次為事件、判斷條件和動作，簡化起來只要寫一個就行。

圖書館借書的狀態圖如下圖所示。

圖書的狀態為在館、被借閱、借出等，該狀態圖就是把狀態連接起來。

狀態圖的注意點：

狀態圖不是流程圖！連起來的是狀態不是動作！看似簡單但很多人第一次繪製都會把狀態圖畫成流程圖類物質。比如上圖中，提交申請、借書等都不是狀態，只能作為動作在連接線上出現。狀態圖的狀態是系統中類的狀態，現實中發生但與系統無關的情況都不能被算作是狀態。比如書被查找中，被翻閱中等現實裡的狀態，並沒有系統的操作，因此不是狀態。四、序列圖

序列圖是用來描述對象之間消息發送的先後次序，闡明對象之間的交互過程以及系統執行過程某一具體時刻將會發生什麼事件。抽象地概括，序列圖就是把主體之間傳遞消息的操作以及消息本身按順序排列出來。

序列圖的元素包括對象、生命線、控制焦點、消息。每個元素的樣式如下圖所示。

序列圖的消息主要分為3種，調用（同步），發送（異步），和返回。同步調用消息是指發送者把控制傳遞給接收者，然後停止活動，等待消息返回。它是一種即時的關係，返回消息需要直接放在這條消息之後。用實心的三角形表示（如上圖的第一條線）。

異步發送消息是指發送者把消息發送過去後，繼續自己的活動，不需要等待消息返回來。返回消息可以在幾個過程之後。用半個箭頭表示（指留下上半個箭頭）。

返回消息就是上述兩種消息調用後所返回的消息，用虛線和普通的箭頭顯示，如上圖。

當然，一般不需要返回的消息用普通箭頭就可以。

圖書館借書的序列圖如下所示。

從員工發起借書申請到借書成功的信息。對象之間的交互包括借書申請、查找、借書操作等。查找書和借書操作需要直接從系統返回消息。

序列圖的注意點：

第一個對象是某操作者，第一步肯定是與系統進行交互。如果畫詳細點的話可以再加個界面，第一步與界面交互，再界面與系統交互。確定哪些情況要同步或者異步的返回信息。返回信息必須是與發送消息的對象一致，方向相反。主體有對象和參與者兩種情況，對象和參與者要區別表示。員工就是參與者，系統是對象。畫圖規範問題，在交互過程中要有連續的控制焦點，不能中斷也不能沒有。五、活動圖

活動圖是展示業務用例實現的工作流程，描述活動活動的順序，展現從一個活動到另一個活動的控制流，強調每一步動作和產生的結果。也就是說，活動圖將系統的活動連接起來，是流程圖的詳細化。

活動圖的元素有動作狀態、動作流、對象、對象流、分支合併，泳道等。活動圖的元素比較豐富，直接用圖書館的案例來分析。

三塊是泳道，分別是不同的對象。黑圓點是開始和結束，中間是活動和順序。矩形是活動中需要涉及到的對象。粗線和菱形是合併分叉的標誌。

整個系統的業務流程如活動的順序所示。發起借書申請時需要傳遞借書申請這個對象，因此需要添加對象。查找圖書後的菱形分叉表示判斷，分出兩個不同的活動。粗線後的兩個活動表示都在借書申請後一步執行。

活動圖的注意點：

菱形和粗線（分叉）很容易錯誤。粗線分叉是和的關係，表示都要做，菱形是或的關係，表示二選一，分開與合併都是這樣，不要搞錯一個活動只能唯一出現在一個泳道，不能跨泳道。對象可以跨泳道。所有活動必須連線，而對象是輔助的作用，去掉對象也要保證所有活動連線。規範問題，比如開始和結束的標記不能漏六、數據流圖

數據流圖雖然並不是UML圖，然而同樣很重要，而且畫圖的難度比較大。數據流圖簡稱DFD，它從數據傳遞和加工角度，以圖形方式來表達系統的邏輯功能、數據在系統內部的邏輯流向和邏輯變換過程。簡單的說，就是數據的流程圖。

數據流圖的元素有外部實體、數據加工、數據存儲和數據流，如下圖所示。

數據流圖的原理，就是把每個數據加工按照順序用數據流連起來。系統外部輸入和輸出的數據則用外部實體來表達。每一步加工需要用到的數據存儲，或者生成的數據存儲，都用數據存儲來表示。每個數據加工都需要按序號命名。

由於系統數據的複雜性，不可能將所有數據操作畫在一張數據流圖上。需要進行分層操作，先畫整體的數據流圖即頂層圖，再逐步細化，分為好幾張圖。

圖書館借書的數據流圖如下：

頂層圖：

0層圖

由於系統比較簡單，因此一共只有兩層圖。頂層是整個系統和外部的數據交換狀態，底層是詳細的數據流動。數據加工分為三塊，借書申請檢查，圖書查找和圖書借閱。借書申請由員工提交，合格的申請發給管理員。

底層圖的加工用1、2等數字命名。如果0層圖後還有1層圖，則用1.1,2.1來命名。如果有1層圖，則需要分多張，如上圖中的加工有1、2、3，則1層圖要分3張，分別描繪這三步加工的詳細步驟。

數據流圖的注意點：

所有步驟都是數據的流動，不要把現實中實體的流動畫進去。比如書，把書給員工，就不是系統中數據的流動，因此不能畫進去。外部實體之間不能有數據傳輸，不能在員工和管理員之間直接畫箭頭。頂層系統只能有1個數據加工，然後一個個展開來，不能在頂層圖畫兩個或以上的數據加工。頂層系統的輸入、輸出數據，應該和所有底層系統的輸入輸出數據一致，不能多出來或少。比如上圖頂層圖中員工的借書申請，管理員的合格申請，在所有底層圖中有且只能有這些數據，不能在員工和管理員的數據流中多出一個數據。如果一層有多幅圖，每幅圖之間的數據要能夠銜接起來。比如2圖書查找和3圖書借閱都有自己的子流程，那麼2圖書查找的數據流圖結束後，就必須輸出圖書信息，3圖書借閱的數據流圖也必須要用到2傳遞的圖書信息。這點原理和上一點一樣。

就寫這麼多。上述的案例是根據自身的業務來制定的，每個圖的案例也有一些地方會不夠完善。

 

本文由 @潘帕斯雄鷹 原創投稿，並經人人都是產品經理編輯。未經許可，禁止轉載。

收藏已收藏 | {{ postmeta.bookmark }} 點讚已贊 | {{ postmeta.postlike }}