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）
定義：
- Java裡的extends，可用于接口與接口之間，或父子類之間
- 單向，箭頭指向父類，如Tiger指向Animal
代碼：
//類
public class Animal {
}
public class Cat extends Animal {
}
//接口
public interface Action {
}
public interface Jump extends Action 2.1.2 實作（Realization）
定義：
- Java裡的implements，箭頭指向接口
- 單向，如Tiger擴充了Sleep接口，那麼箭頭指向Sleep
代碼：
public interface Jump {
}
public class Tiger implements Jump 2.1.3 依賴（Dependency）
定義：
- 某個類或對象執行個體，依賴于另一個而存在，在其關鍵方法中用到了對方
- 如果一方屬性發生變動，另一方可能會收到影響
- 一般為單向，例如動物依賴于食物，eat(Food food)
- 類比在表結構上，更像是外鍵
代碼：方法參數，局部變量
2.1.4 關聯（Association）
定義：
- 是一種擁有的關系，雙方不一定屬于同一類事物，箭頭指向被擁有者
- 可以單向，也可以雙向，例如Tiger與Zookeeper
- 類比在表結構上，更像是存在中間表關系
代碼：成員變量
2.1.5 聚合（Aggregation）
定義：
- 單向，空心菱形起始的箭頭，箭頭指向被擁有者
- 一種很弱的擁有關系，A可以擁有B，但是不是離了B就無法生存
- 群體與個體的關系，如小組包含組員
代碼：成員變量，多為集合
2.1.6 組合（Composition）
定義：
- 單向，實心菱形為起始，箭頭指向子子產品
- 一種整體與部分的關系，A是由B組成的，離開B則不完整。
- 單向，如人和四肢的關系
代碼：成員變量，多為集合
2.1.7 執行個體
一張圖涵蓋所有的關系：
2.1.8 總結
- 繼承和實作幾乎不會搞混，一個上下父子關系，一個是類與接口
- 組合與聚合要注意，聚合為聚集，群體與個體。組合為組成，整體與部分
- 關聯和依賴要注意，關聯一般為同級别有相關性，這種相關性是長期存在的。依賴為需求關系，一方需要依賴另一方，可能會因另一方的改變而改變。
- 關系的強弱順序：繼承=實作>組合>聚合>關聯>依賴
2.2 圖
2.2.1 概述
UML中的圖形非常多，按類型分為結構圖和行為圖，其中，最常用，最典型的為9種，下面分開來介紹。
- 用例圖：從使用者角度描述系統功能。
- 類圖：描述系統中類的靜态結構。
- 對象圖：系統中的多個對象在某一時刻的狀态。
- 狀态圖：是描述狀态到狀态控制流，用于表達系統狀态的變化
- 活動圖：描述了業務實作用例的工作流程，強調的是動作之間的銜接
- 序列圖：對象之間的動态合作關系，強調對象發送消息的順序
- 協作圖：描述對象之間的協助關系，強調對象之間的合作關系
- 元件圖：描述系統各個元件及其相關關系的靜态視圖
- 部署圖：定義系統中軟硬體的實體體系結構
2.2.2 類圖
1）說明
- 面向對象系統模組化中最常用和最重要的圖，是定義其它圖的基礎
- 主要是用來顯示系統中的類、接口以及它們之間的靜态結構和關系的一種靜态模型
- 描述細化相關的屬性和操作，是一個對業務模型面向對象化的過程，也是對系統的限制
- 可以直接建構可執行代碼，但真正使用的場景相對較少
2）可用元素
- 類：
- 接口：
- 關系：可以使用上述中的6大關系。
3）執行個體
2.2.3 對象圖
1）說明
- 對象圖和類圖一樣反映系統的靜态過程，但它表達的是一個實際場景。
- 對象圖顯示某時刻對象和對象之間的關系。可看成一個類圖的快照。
- 對象圖是類圖的執行個體，是以幾乎使用與類圖完全相同的辨別。
2）可用元素
- 對象：
3）關系
對象圖因為是運作在某個時間節點的對象鏡像，是以關系比較單一，描述的是類與類的執行個體之間。不涉及接口
- 關聯：對象之間存在關聯關系，如使用者和訂單
- 依賴：對象執行個體之間的依賴關系，如商品對象依賴店鋪
4）圖例
2.2.4 元件圖
1）說明
- UML1.1中，元件圖是用來描述一個系統的實體構件。包括檔案，可執行檔案，庫等
- UML2 中，關注元件間的關聯（使用什麼接口，通過什麼端口通訊），強調通過接口來描述元件行為
- 對于後端來說，元件圖比較适用于 SOA 架構、微服務架構，描述整個系統的結構以及子系統間的通訊方式
- 對于前端來說，元件圖适合在使用類似 react、vue 這樣元件化的前端技術架構時，表達對元件的設計，比如一個頁面會有個骨架元件，骨架元件包含了導航元件，清單元件等等
2）可用元素
- 元件：描述的是系統的其中一個組成部分，一個完整的可獨立服務的子產品或單元，比如訂單服務，k8s裡的一個pod
- 部件：元件内可能細化為多個子子產品
- 端口：元件對外提供服務就必須暴露對應的端口。如http rest服務預設的80
- 接口：部件/元件之間的一種約定，分提供者和需求者同時展示了某個部件提供出的功能
3）關系
- 泛化：用于接口與接口之間存在的父子關系，元件之間也可能存在，但相對用的較少
- 實作：接口和其實作者（提供服務的元件）之間
- 關聯：Require link / Connector ，接口與調用者（需要接口的元件）之間
4）圖例
2.2.5 部署圖
1）說明
- 一種展示運作時進行處理的節點和在節點上存在的元件配置的圖。
- 闡述了在實際應用中軟體和它的運作環境的關系，并且描述了軟體部署在硬體上的具體方式。
2）可用元素
-
節點：
早先單執行個體MVC架構下，節點可以認為是某台實體伺服器，微服務及容器化下，實體伺服器大多納入編排管理，docker執行個體由系統在實體節點見自由排程，元件無法鎖定在某個固定實體節點上，這種環境下的node可以了解為一個容器，或k8s中的pod。
-
元件執行個體
相當于元件裡的執行個體化，類比于類和對象
3）關系
- 依賴：發生于元件之間，如使用者元件依賴于訂單元件
- 關聯：node association，發生于節點之間，例如應用伺服器需要關聯mysql資料庫
4）圖例
2.2.6 用例圖
1）說明
- 用例圖是用來描述系統功能的技術，表示一個系統中用例與參與者及其關系的圖
- 主要用于需求分析階段，和産品文檔比較貼近
- 用例圖相當于從使用者的視角來描述和模組化整個系統，分析系統的功能與行為。
2）可用元素
- 參與者：使用系統的人，有多少種角色就有多少參與者。
- 用例：參與者可用做的事情
3）關系
- 泛化：參與者之間可用泛化，例如使用者與普通會員；用例也可用泛化，如使用者管理與修改密碼
- 關聯：發生于參與者和用例之間，表示該角色可用有哪些用例（行為）
- 依賴：發生與用例之間，例如登入依賴于注冊
4）圖例
2.2.7 互動圖
互動圖分為序列圖和協作圖，兩者既可以互相轉換而不丢失資訊，又存在一定差異。下面分開講再類比
序列圖
1）說明
- 序列圖主要用于按照互動發生的一系列順序，顯示對象之間的消息或行為傳遞。
- 序列圖可以形象表達整個流程，和流程圖有相似之處，但是流程圖偏業務邏輯，序列圖則是系統面向對象化模組化後，對應到對象上的互動過程。趨向于開發者角度。
2）可用元素
- 對象：提供功能和互動的類的執行個體
- 參與者：同用例種的參與人，多為一段流程的發起點
- 時間線：對象在整個互動流程中的生命周期
- 消息：對象間需要發送和傳回的消息，可以自己發給自己
- 外部參考：序列圖可以引入外部的一段作為參考，或參與序列中與目前圖的元素互動
- 片段：将某一段序列納入片段管理，該片段像原子一樣，發生某些整體的行為，例如循環
3）關系
- 不會用到6大關系，互相之間使用message互動。代表的是資訊流動。
4）圖例
協作圖（1.4）/通信圖（2.0）
1）說明
- 協作圖與時序圖類似，二者都是用對象間的互動來描述用例的。
- 兩者關注角度稍有不同，時序圖強調互動的時間次序，協作圖強調互動的空間結構。
2）可用元素
- 參與者：系統參與的角色
- 對象：同時序圖，系統中執行個體化的對象
- 關聯：對象間的關聯關系
- 消息：依附于關聯而存在，承載了對象間要傳遞的資訊
3）關系
- 不會用到6大關系，互相之間使用message互動。代表的是資訊流動。
4）圖例
兩種互動圖可以互相轉化，類比如下：
2.2.8 狀态機
狀态機分為狀态圖和活動圖，
狀态圖
1）說明
- 描述一個實體基于事件反應的動态行為，它有兩方面的價值，一是反映對象可能有哪些狀态，二是這些狀态之間是如何流轉的，需要什麼樣的條件下進入什麼樣的狀态。
2）可用元素
- 狀态：某一個時間點，對象所在的狀态
- 轉移：連接配接狀态之間，因為狀态時可以互相變化轉移的
- 分支/會合點：狀态變化中可能産生分叉或交會，如确認收貨後，雙方互評産生分叉
- 開始/結束：狀态的起始與終結
- 同步點：需要多個分支狀态都具備時使用。多用于并行協作處理的狀态流轉，如互評都完成後，訂單才算終結
3）關系
- 隻有轉移關系，表示狀态之間的變化
4）圖例
活動圖
1）說明
- 活動圖用于企業的業務流程模組化，是對内部活動與活動之間流轉動作的表達
- 活動圖類比流程圖：活動圖存在分支與交會，可以表達并行存在的活動，流程圖多為是與否分支判斷
- 活動圖類比狀态圖：關注不同，狀态圖強調行為的結果（下一個狀态是什麼），活動圖在乎行為的動作（下一步幹什麼）。兩者可以了解為穿插配合，一動一靜，活動可能會觸發下一步不同的狀态。
2）可用元素
- 活動：表達系統中，或對象内的某一個可以發生的動作
- 對象：活動的發生者，或互動者
- 流轉：活動的跳轉，即下一步指向誰
- 判定：類似與流程圖裡的判決，根據條件産生不同的流轉
- 同步：并行流轉下的彙集，不同于流程圖的地方
- 起始/結束：活動的發起與終結
- 泳道：對UML活動圖中的活動進行分組，同一類活動在一個泳道上，清晰明了
3）關系
- 隻有流轉，也就是活動的跳轉，表示下一個活動是啥
4）圖例
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中，而是由排程器動态排程，分散部署。
- node：App1，App2，App3，假設有三台；mysql資料庫，假設1主2從
- component：Order，Cart，Pay，Promotion
- 元件離散分布于3台App
- App關聯mysql
- mysql主從為依賴
3.3 總結
- 一切皆工具，适合你的就是最好的
- 靈活變通，不要拘泥規矩，規矩是死的人是活的
- 表達思想才是目的，一切都是為了能說清楚你的想法，這也是語言的本質
-
不要為了畫圖而畫圖，UML不是必須的，但是有了它你的架構工作會變得更順暢
希望UML能成為你架構工作的利器，提升效率，解決問題。Thanks！