UML系統建模

1 概述

1.1 課程概述

匯集UML及其相關的一些話題
回顧UML相關的符號與概念
以電商訂單相關業務為例，借助UML完成系統建模
將UML變成提升建模效率，表達架構思想的工具

1.2 什么是UML

? Unified Modeling Language 統一建模語言，又稱標準建模語言，是用來對軟體密集系統進行可視化建模的一種語言，語言，也就是一個表達思想的符號約定，

1.3 UML的發展與版本

建模語言出現在二十世紀70年代，80年代末開始迅速發展，建模語言達到了50多種，百家爭鳴
后來，Rumbaugh 于1994年加入Booch所在的Rational公司，他們一起研究一種統一的方法
一年后，Unified Method 0.8誕生
經過他們三年的共同努力，UML0.9和UML0.91于1996年相繼面世，
此后UML創始人Booch等人，邀請計算機界的知名人士與企業IBM，HP，Microsoft，Oracle等對UML進行評論，聽取意見，
1997年1月，Rational公司向OMG（物件管理組織）提交了UML1.0
1997年11月，OMG宣布接受UML，認定為標準的建模語言
1998年發布了UML 1.2
1999年發布了UML 1.3
2003年3月發布了UML 1.5
2004年推出UML2.0

1.4 UML可以做什么

? 從命名上分析：統一、建模、語言

? 統一：沒有規矩不成方圓，它指定了一種標準，一種約束，使得大家的表達變得一致，它被OMG（Object Management Group）所認可，

	OMG是一個國際化的、開放成員的、非盈利性的計算機行業標準協會，該協會成立于1989年，他是軟體行業中一個標準的認可，包括客戶、領域專家、分析師、設計師、程式員、測驗工程師及培訓人員等，UML成為他們作業中統一的溝通工具，用于充分理解和表達自己所關注的內容，

? 建模：復雜業務系統建模，即建立軟體系統模型，UML的創始人之一Booch，曾用建一座摩天大樓來比喻UML的必要性，簡單系統下，可有可無，系統復雜或大到一定程度，建模和檔案成為系統周期里非常重要的一環，

? 語言：面向物件思想的表達，互相之間的溝通工具，一種按照特定規則和模式組成的符號系統，

1.5 學習UML的意義

團隊或架構設計互相交流，必然需要一種溝通語言
是一門技能，不一定用到，但是作為架構師應該知道
有其他的表達辦法，但是用習慣后，UML真的很方便易用

1.6 關于UML的爭議

? 觀點一：UML是雞肋，離程式員真正需要的設計工具還差得很遠，只有為數不多的程式員使用這個工具交流想法，而沒有用在具體作業中，

? 觀點二：UML設計相當的嚴謹與全面，在面向物件的系統架構上，可以便捷的表達你想要表達的一切想法，優美切無可替代，

? 個人觀點：一項技能和工具，學會并不難，需要的時候能拿來用就好，藝不壓身，

1.7 切忌形式化

不要把UML過度神化
一個表達想法的工具而已
當用則用，不要刻意去套

2 理論篇

2.1 關系

關系是現實世界中事物與事物之間相互關系的符號表達，抽象到面向物件理念上，大致分為6種，

2.1.1 泛化（Generalization）

file
定義：

Java里的extends，可用于介面與介面之間，或父子類之間
單向，箭頭指向父類，如Tiger指向Animal

代碼：

//類
public class Animal {
}
public class Cat extends Animal {
}

//介面
public interface Action {
}
public interface Jump extends Action {
}

2.1.2 實作（Realization）

file
定義：

Java里的implements，箭頭指向介面
單向，如Tiger擴展了Sleep介面，那么箭頭指向Sleep

代碼：

public interface Jump {
}
public class Tiger implements Jump {
}

2.1.3 依賴（Dependency）

file
定義：

某個類或物件實體，依賴于另一個而存在，在其關鍵方法中用到了對方
如果一方屬性發生變動，另一方可能會收到影響
一般為單向，例如動物依賴于食物，eat(Food food)
類比在表結構上，更像是外鍵

代碼：方法引數，區域變數

2.1.4 關聯（Association）

file
定義：

是一種擁有的關系，雙方不一定屬于同一類事物，箭頭指向被擁有者
可以單向，也可以雙向，例如Tiger與Zookeeper
類比在表結構上，更像是存在中間表關系

代碼：成員變數

2.1.5 聚合（Aggregation）

file
定義：

單向，空心菱形起始的箭頭，箭頭指向被擁有者
一種很弱的擁有關系，A可以擁有B，但是不是離了B就無法生存
群體與個體的關系，如小組包含組員

代碼：成員變數，多為集合

2.1.6 組合（Composition）

file
定義：

單向，實心菱形為起始，箭頭指向子模塊
一種整體與部分的關系，A是由B組成的，離開B則不完整，
單向，如人和四肢的關系

代碼：成員變數，多為集合

2.1.7 實體

一張圖涵蓋所有的關系：

file

2.1.8 總結

繼承和實作幾乎不會搞混，一個上下父子關系，一個是類與介面
組合與聚合要注意，聚合為聚集，群體與個體，組合為組成，整體與部分
關聯和依賴要注意，關聯一般為同級別有相關性，這種相關性是長期存在的，依賴為需求關系，一方需要依賴另一方，可能會因另一方的改變而改變，
關系的強弱順序：繼承=實作>組合>聚合>關聯>依賴

2.2 圖

2.2.1 概述

file
? UML中的圖形非常多，按型別分為結構圖和行為圖，其中，最常用，最典型的為9種，下面分開來介紹，

用例圖：從用戶角度描述系統功能，
類圖：描述系統中類的靜態結構，
物件圖：系統中的多個物件在某一時刻的狀態，
狀態圖：是描述狀態到狀態控制流，用于表達系統狀態的變化
活動圖：描述了業務實作用例的作業流程，強調的是動作之間的銜接
序列圖：物件之間的動態合作關系，強調物件發送訊息的順序
協作圖：描述物件之間的協助關系，強調物件之間的合作關系
組件圖：描述系統各個組件及其相關關系的靜態視圖
部署圖：定義系統中軟硬體的物理體系結構

2.2.2 類圖

1）說明

面向物件系統建模中最常用和最重要的圖，是定義其它圖的基礎
主要是用來顯示系統中的類、介面以及它們之間的靜態結構和關系的一種靜態模型
描述細化相關的屬性和操作，是一個對業務模型面向物件化的程序，也是對系統的約束
可以直接構建可執行代碼，但真正使用的場景相對較少

2）可用元素

file

類：

file

介面：

file

關系：可以使用上述中的6大關系，

3）實體

file

2.2.3 物件圖

1）說明

物件圖和類圖一樣反映系統的靜態程序，但它表達的是一個實際場景，
物件圖顯示某時刻物件和物件之間的關系，可看成一個類圖的快照，
物件圖是類圖的實體，所以幾乎使用與類圖完全相同的標識，

2）可用元素

file

物件：

file
3）關系

物件圖因為是運行在某個時間節點的物件鏡像，所以關系比較單一，描述的是類與類的實體之間，不涉及介面

關聯：物件之間存在關聯關系，如用戶和訂單
依賴：物件實體之間的依賴關系，如商品物件依賴店鋪

4）圖例

file

2.2.4 組件圖

1）說明

UML1.1中，組件圖是用來描述一個系統的物理構件，包括檔案，可執行檔案，庫等
UML2 中，關注組件間的關聯（使用什么介面，通過什么埠通訊），強調通過介面來描述組件行為
對于后端來說，組件圖比較適用于 SOA 架構、微服務架構，描述整個系統的結構以及子系統間的通訊方式
對于前端來說，組件圖適合在使用類似 react、vue 這樣組件化的前端技術框架時，表達對組件的設計，比如一個頁面會有個骨架組件，骨架組件包含了導航組件，串列組件等等

2）可用元素

file
file

組件：描述的是系統的其中一個組成部分，一個完整的可獨立服務的模塊或單元，比如訂單服務，k8s里的一個pod
部件：組件內可能細化為多個子模塊
埠：組件對外提供服務就必須暴露對應的埠，如http rest服務默認的80
介面：部件/組件之間的一種約定，分提供者和需求者同時展示了某個部件提供出的功能

3）關系

泛化：用于介面與介面之間存在的父子關系，組件之間也可能存在，但相對用的較少
實作：介面和其實作者（提供服務的組件）之間
關聯：Require link / Connector ，介面與呼叫者（需要介面的組件）之間

4）圖例

file

2.2.5 部署圖

1）說明

一種展示運行時進行處理的節點和在節點上存在的組件配置的圖，
闡述了在實際應用中軟體和它的運行環境的關系，并且描述了軟體部署在硬體上的具體方式，

2）可用元素

file

節點：

早先單實體MVC架構下，節點可以認為是某臺物理服務器，微服務及容器化下，物理服務器大多納入編排管理，docker實體由系統在物理節點見自由調度，組件無法鎖定在某個固定物理節點上，這種環境下的node可以理解為一個容器，或k8s中的pod，

file

組件實體

相當于組件里的實體化，類比于類和物件

file
3）關系

依賴：發生于組件之間，如用戶組件依賴于訂單組件
關聯：node association，發生于節點之間，例如應用服務器需要關聯mysql資料庫

4）圖例

file

2.2.6 用例圖

1）說明

用例圖是用來描述系統功能的技術，表示一個系統中用例與參與者及其關系的圖
主要用于需求分析階段，和產品檔案比較貼近
用例圖相當于從用戶的視角來描述和建模整個系統，分析系統的功能與行為，

2）可用元素

file

參與者：使用系統的人，有多少種角色就有多少參與者，

file

用例：參與者可用做的事情

file

3）關系

泛化：參與者之間可用泛化，例如用戶與普通會員；用例也可用泛化，如用戶管理與修改密碼
關聯：發生于參與者和用例之間，表示該角色可用有哪些用例（行為）
依賴：發生與用例之間，例如登錄依賴于注冊

4）圖例

file

2.2.7 互動圖

互動圖分為序列圖和協作圖，兩者既可以相互轉換而不丟失資訊，又存在一定差異，下面分開講再類比

序列圖

1）說明

序列圖主要用于按照互動發生的一系列順序，顯示物件之間的訊息或行為傳遞，
序列圖可以形象表達整個流程，和流程圖有相似之處，但是流程圖偏業務邏輯，序列圖則是系統面向物件化建模后，對應到物件上的互動程序，趨向于開發者角度，

2）可用元素

file

物件：提供功能和互動的類的實體
參與者：同用例種的參與人，多為一段流程的發起點
時間線：物件在整個互動流程中的生命周期
訊息：物件間需要發送和回傳的訊息，可以自己發給自己
外部參考：序列圖可以引入外部的一段作為參考，或參與序列中與當前圖的元素互動
片段：將某一段序列納入片段管理，該片段像原子一樣，發生某些整體的行為，例如回圈

3）關系

不會用到6大關系，相互之間使用message互動，代表的是資訊流動，

4）圖例

file

協作圖（1.4）/通信圖（2.0）

1）說明

協作圖與時序圖類似，二者都是用物件間的互動來描述用例的，
兩者關注角度稍有不同，時序圖強調互動的時間次序，協作圖強調互動的空間結構，

2）可用元素

file

參與者：系統參與的角色
物件：同時序圖，系統中實體化的物件
關聯：物件間的關聯關系
訊息：依附于關聯而存在，承載了物件間要傳遞的資訊

3）關系

不會用到6大關系，相互之間使用message互動，代表的是資訊流動，

4）圖例

? 兩種互動圖可以相互轉化，類比如下：

file

2.2.8 狀態機

狀態機分為狀態圖和活動圖，

狀態圖

1）說明

描述一個物體基于事件反應的動態行為，它有兩方面的價值，一是反映物件可能有哪些狀態，二是這些狀態之間是如何流轉的，需要什么樣的條件下進入什么樣的狀態，

2）可用元素

file

狀態：某一個時間點，物件所在的狀態
轉移：連接狀態之間，因為狀態時可以互相變化轉移的
分支/會合點：狀態變化中可能產生分叉或交會，如確認識訓后，雙方互評產生分叉
開始/結束：狀態的起始與終結
同步點：需要多個分支狀態都具備時使用，多用于并行協作處理的狀態流轉，如互評都完成后，訂單才算終結

3）關系

只有轉移關系，表示狀態之間的變化

4）圖例

file

活動圖

1）說明

活動圖用于企業的業務流程建模，是對內部活動與活動之間流轉動作的表達
活動圖類比流程圖：活動圖存在分支與交會，可以表達并行存在的活動，流程圖多為是與否分支判斷
活動圖類比狀態圖：關注不同，狀態圖強調行為的結果（下一個狀態是什么），活動圖在乎行為的動作（下一步干什么），兩者可以理解為穿插配合，一動一靜，活動可能會觸發下一步不同的狀態，

2）可用元素

file

活動：表達系統中，或物件內的某一個可以發生的動作
物件：活動的發生者，或互動者
流轉：活動的跳轉，即下一步指向誰
判定：類似與流程圖里的判決，根據條件產生不同的流轉
同步：并行流轉下的匯集，不同于流程圖的地方
起始/結束：活動的發起與終結
泳道：對UML活動圖中的活動進行分組，同一類活動在一個泳道上，清晰明了

3）關系

只有流轉，也就是活動的跳轉，表示下一個活動是啥

4）圖例

file

3 實戰篇

3.1 常用工具

3.1.1 Rational Rose

? 老牌，大名鼎鼎，史上最有名的UML產品，以至于大多數情況下，很多人將他等同于UML工具，需要注意的是，自從 Rational被IBM收購之后，Rational Rose已經成為歷史，作為UML1.4標準的產物，現在已經不升級，但是夠用，其替代品是IBM的其他產品，如IBM RSA，

3.1.2 RSA

? IBM? Rational? Software Architect ，IBM的旗艦產品，是一個高級而又全面的應用程式設計、建模和開發工具，用于實作端到端的軟體交付，通過和IBM其他產品的協調，支持軟體開發的全生命周期開發，但是也有它的缺點，笨重，繁雜（大公司產品的通病？？？）

3.1.3 Enterprise Architect

? Sparx Systems 公司的旗艦產品，它覆寫了系統開發的整個周期，除了開發類模型之外，還包括事務行程分析，使用案例需求，動態模型，組件和布局，系統管理，非功能需求，用戶界面設計，測驗和維護等，總之你需要的基本都可以滿足，價格還便宜，性價比之選，

3.1.4 StarUML

? 開放原始碼的UML開發工具，是由韓國公司主導開發出來的產品，用Delphi寫的，是個大神，需要付費，網站提供購買注冊碼，小巧簡單而易用，與rose相比更是明顯，

3.1.5 VISIO

? VISIO可以理解為一種通用的畫圖工具，它具備常見的各種圖形，從VISIO2000版本才開始涉足軟體分析設計到代碼生成的全部功能，單純從畫圖角度，有著無可比擬的優勢，UML圖示僅僅是其中很少的一部分，優點是跟微軟的office產品的能夠很好兼容，可以把圖形直接復制或者內嵌到WORD的檔案中，但是到代碼的生成更多是支持微軟自家的產品如VB，C#，ms sql 等（微軟的一貫作風），如果僅是畫UML圖和大量的word檔案表達，它可以滿足你，

3.1.6 PowerDesigner

? Sybase的企業建模和設計解決方案，采用模型驅動方法，將業務與IT結合起來，可幫助部署有效的企業體系架構，并為研發生命周期管理提供強大的分析與設計技術，將多種標準資料建模技術集成一體，并與IDE集成，典型的如Eclipse 插件形式，PD更多給人的印象是資料庫建模技術，但是它可以完成UML的所有建模操作并映射到資料庫和代碼層面，并提供60多種關系資料庫的連接支持，

3.1.7 總結

以上工具各有利弊，根據自己實際情況和愛好選擇即可
基本都涵蓋軟體建模的完整周期，UML只是他們的一部分功能
任何一種都可以滿足你學習和作業中UML建模的使用需求

3.2 訂單建模實戰

3.2.1 B2C交易用例圖

用例圖從訂單系統使用人角色出發，反饋訂單體系里面有哪些人，可以做哪些事情

1）業務需求：

買家：瀏覽商品，下單、支付、簽收
賣家：開店，確認訂單，發貨，商品維護
雙方：退貨，換貨，評價，收藏

3.2.2 訂單模塊類圖

訂單類圖從業務模型出發，用面向物件思想，訂單業務中的模型抽象為一個個物件

1）元素：

人物類：Seller，Buyer，User
商品類：Shop，Product
交易環節類：Cart，Order，Invoice，AliPay，WeichatPay，ICBCPay...
交易環節介面：Pay
促銷相關類：DiscountPromotion，ReductionPromotion...
促銷介面：Promotion

2）關系：

關聯：Order→Seller，Buyer，Pay；Shop→Seller
依賴：Order→Cart→Promotion，Invoice；
組合：Shop→Product
聚合：Cart→Product
泛化：Buyer，Seller→User
實作：DiscountPromotion，ReductionPromotion→Promotion；AliPay，WeichatPay，ICBCPay→Pay

3.2.3 訂單下單時的物件圖

物件圖表達的是下訂單的時刻，系統存在的物件及物件之間的關聯關系，物件具備了實際的屬性值

1）元素：

與類圖一致，但是介面將不復存在，而變為實際實作類
Cart生命周期終結，Invoice還沒誕生，Product，Promotion依附在了訂單上
物件上的屬性具備了實際值，不再是泛化的類屬性的概念

2）關系：

物件之間變為實體關聯（Instance link），泛化和實作不再被使用，
弱型別可以使用依賴，比如Order與打折的Promotion

3.2.4 B2C下單支付序列圖

序列圖反應下單到支付完成這段時間里，各個物件怎么協作和互動，互相之間需要傳遞什么訊息，

1）元素

人物：Buyer
物件：Product，Cart，Order，Promotion，Pay，AliPay（外部）

2）時間序列

順向：Buyer→篩選→Product→添加→Cart→促銷結算→Promotion→下單→Order→支付→Pay→跳轉→AliPay
回路：Buyer←通知←Order←開單←Pay←回呼←AliPay
環路：Cart ←→增刪商品

3.2.5 下單支付協作圖

協作圖同序列圖類似，可以由序列圖轉化而來，但是協作圖反映的是互動關系，像是鋪開的時序圖

1）元素，同時序圖

人物：Buyer
物件：Product，Cart，Order，Promotion，Pay，AliPay（外部）

2）互動，同序列圖

關聯
訊息

3.2.6 B2B先款后貨狀態圖

以B2B先款后貨業務模式下，訂單物件的流轉狀態為例，實作業務狀態展示

1）元素

起始
訂單的各個狀態值
交會
同步
終結

2）流轉

開始→合同已生成→已付款→交收單已生成→已發貨→驗貨驗票→待評價→分支→買方已評，賣方已評→同步→終結

3.2.7 B2B先款后歡訓動圖

在先款后貨的交易中，雙方都要做哪些活動或者說操作，通過活動圖建模體現

1）元素

泳道：Buyer，Seller，Manager
活動（Buyer）：生成合同，支付貨款，驗貨驗票，買方評價
活動（Seller）：生成交收單，發貨，賣方評價
活動（Manager）：仲裁
判定：是否有異議

2）流程

開始→生成合同→支付貨款→生成交收單→發貨→驗票驗貨→判斷（是否異議？）→否→分支→買方，賣方評價→同步→終結
判斷異議→是→仲裁→終結

3.2.8 訂單服務組件圖

界定構成訂單服務的各個物件以及他們之間的可用介面，相當于定義了一組約定，

1）元素

Order：create（Cart），open（Pay）
Cart：addProduct（Buyer），removeProduct（Buyer），settle（Buyer）
Promotion：discount（Cart）
Pay：pay（Buyer）

3.2.9 訂單中心部署圖

? 將訂單中心如何部署到服務器？部署圖的職責就是完成這部分的內容，在docker容器化編排和云環境下，部署圖變得不那么的確切，node可以類比理解為docker容器或者是k8s等編排工具中的pod，而組件也不再固定在某個node中，而是由調度器動態調度，分散部署，

1）元素

node：App1，App2，App3，假設有三臺；mysql資料庫，假設1主2從
component：Order，Cart，Pay，Promotion

2）關系

組件離散分布于3臺App
App關聯mysql
mysql主從為依賴

3.3 總結

一切皆工具，適合你的就是最好的
靈活變通，不要拘泥規矩，規矩是死的人是活的
表達思想才是目的，一切都是為了能說清楚你的想法，這也是語言的本質
不要為了畫圖而畫圖，UML不是必須的，但是有了它你的架構作業會變得更順暢

希望UML能成為你架構作業的利器，提升效率，解決問題，Thanks！

本文由傳智教育博學谷 - 狂野架構師教研團隊發布
轉載請注明出處！

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/491271.html

標籤：Java

上一篇：如果我在ElasticSearch中需要特殊的分析器，我該怎么辦

下一篇：【Java面試】Mybatis中#{}和${}的區別是什么？

想學設計模式、想搞架構設計，先學學UML系統建模吧您

UML系統建模

1 概述

1.1 課程概述

1.2 什么是UML

1.3 UML的發展與版本

1.4 UML可以做什么

1.5 學習UML的意義

1.6 關于UML的爭議

1.7 切忌形式化

2 理論篇

2.1 關系

2.1.1 泛化（Generalization）

2.1.2 實作（Realization）

2.1.3 依賴（Dependency）

2.1.4 關聯（Association）

2.1.5 聚合（Aggregation）

2.1.6 組合（Composition）

2.1.7 實體

2.1.8 總結

2.2 圖

2.2.1 概述

2.2.2 類圖

2.2.3 物件圖

2.2.4 組件圖

2.2.5 部署圖

2.2.6 用例圖

2.2.7 互動圖

2.2.8 狀態機

3 實戰篇

3.1 常用工具

3.1.1 Rational Rose

3.1.2 RSA

3.1.3 Enterprise Architect

3.1.4 StarUML

3.1.5 VISIO

3.1.6 PowerDesigner

3.1.7 總結

3.2 訂單建模實戰

3.2.1 B2C交易用例圖

3.2.2 訂單模塊類圖

3.2.3 訂單下單時的物件圖

3.2.4 B2C下單支付序列圖

3.2.5 下單支付協作圖

3.2.6 B2B先款后貨狀態圖

3.2.7 B2B先款后歡訓動圖

3.2.8 訂單服務組件圖

3.2.9 訂單中心部署圖

3.3 總結