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

博學谷狂野架構師 發表於 2022-06-13
設計模式

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!

本文由傳智教育博學谷 - 狂野架構師教研團隊釋出
轉載請註明出處!