1 概述

1.1 課程概述

• 匯集uml及其相關(guān)的一些話題
• 回顧uml相關(guān)的符號與概念
• 以電商訂單相關(guān)業(yè)務(wù)為例，借助uml完成系統(tǒng)建模
• 將uml變成提升建模效率，表達(dá)架構(gòu)思想的工具

1.2 什么是uml

Unified Modeling Language 統(tǒng)一建模語言，又稱標(biāo)準(zhǔn)建模語言。是用來對軟件密集系統(tǒng)進(jìn)行可視化建模的一種語言。語言，也就是一個(gè)表達(dá)思想的符號約定。

1.3 uml的發(fā)展與版本

• 建模語言出現(xiàn)在二十世紀(jì)70年代，80年代末開始迅速發(fā)展，建模語言達(dá)到了50多種，百家爭鳴
• 后來，Rumbaugh 于1994年加入Booch所在的Rational公司，他們一起研究一種統(tǒng)一的方法
• 一年后，Unified Method 0.8誕生
• 經(jīng)過他們?nèi)甑墓餐Γ琔ML0.9和UML0.91于1996年相繼面世。
• 此后UML創(chuàng)始人Booch等人，邀請計(jì)算機(jī)界的知名人士與企業(yè)IBM，HP，Microsoft，Oracle等對UML進(jìn)行評論，聽取意見。
• 1997年1月，Rational公司向OMG（對象管理組織）提交了UML1.0
• 1997年11月，OMG宣布接受UML，認(rèn)定為標(biāo)準(zhǔn)的建模語言
• 1998年發(fā)布了UML 1.2
• 1999年發(fā)布了UML 1.3
• 2003年3月發(fā)布了UML 1.5
• 2004年推出UML2.0

1.4 uml可以做什么

從命名上分析：統(tǒng)一、建模、語言

統(tǒng)一：沒有規(guī)矩不成方圓，它指定了一種標(biāo)準(zhǔn)，一種約束，使得大家的表達(dá)變得一致。它被OMG（ObjectManagement Group）所認(rèn)可。

建模：復(fù)雜業(yè)務(wù)系統(tǒng)建模，即建立軟件系統(tǒng)模型。uml的創(chuàng)始人之一Booch，曾用建一座摩天大樓來比喻uml的必要性。簡單系統(tǒng)下，可有可無，系統(tǒng)復(fù)雜或大到一定程度，建模和文檔成為系統(tǒng)周期里非常重要的一環(huán)。

語言：面向?qū)ο笏枷氲谋磉_(dá)。互相之間的溝通工具。一種按照特定規(guī)則和模式組成的符號系統(tǒng)。

1.5 學(xué)習(xí)uml的意義

• 團(tuán)隊(duì)或架構(gòu)設(shè)計(jì)互相交流，必然需要一種溝通語言
• 是一門技能，不一定用到，但是作為架構(gòu)師應(yīng)該知道
• 有其他的表達(dá)辦法，但是用習(xí)慣后，uml真的很方便易用

1.6 關(guān)于uml的爭議

觀點(diǎn)一：uml是雞肋，離程序員真正需要的設(shè)計(jì)工具還差得很遠(yuǎn)。只有為數(shù)不多的程序員使用這個(gè)工具交流想法，而沒有用在具體工作中。

觀點(diǎn)二：uml設(shè)計(jì)相當(dāng)?shù)膰?yán)謹(jǐn)與全面，在面向?qū)ο蟮南到y(tǒng)架構(gòu)上，可以便捷的表達(dá)你想要表達(dá)的一切想法，優(yōu)美切無可替代。

個(gè)人觀點(diǎn)：一項(xiàng)技能和工具，學(xué)會并不難，需要的時(shí)候能拿來用就好，藝不壓身。

1.7 切忌形式化

• 不要把uml過度神化
• 一個(gè)表達(dá)想法的工具而已
• 當(dāng)用則用，不要刻意去套

2 理論篇

2.1 關(guān)系

關(guān)系是現(xiàn)實(shí)世界中事物與事物之間相互關(guān)系的符號表達(dá)，抽象到面向?qū)ο罄砟钌?，大致分?種。

2.1.1 泛化（Generalization）

定義：

• java里的extends，可用于接口與接口之間，或父子類之間
• 單向，箭頭指向父類，如Tiger指向Animal

代碼：

2.1.2 實(shí)現(xiàn)（Realization）

定義：

• java里的implements，箭頭指向接口
• 單向，如Tiger擴(kuò)展了Sleep接口，那么箭頭指向Sleep

代碼：

2.1.3 依賴（Dependency）

定義：

• 某個(gè)類或?qū)ο髮?shí)例，依賴于另一個(gè)而存在，在其關(guān)鍵方法中用到了對方
• 如果一方屬性發(fā)生變動(dòng)，另一方可能會收到影響
• 一般為單向，例如動(dòng)物依賴于食物，eat(Food food)
• 類比在表結(jié)構(gòu)上，更像是外鍵

代碼：方法參數(shù)，局部變量

2.1.4 關(guān)聯(lián)（Association）

定義：

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

代碼：成員變量

2.1.5 聚合（Aggregation）

定義：

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

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

2.1.6 組合（Composition）

定義：

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

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

2.1.7 實(shí)例

一張圖涵蓋所有的關(guān)系：

2.1.8 總結(jié)

• 繼承和實(shí)現(xiàn)幾乎不會搞混，一個(gè)上下父子關(guān)系，一個(gè)是類與接口
• 組合與聚合要注意，聚合為聚集，群體與個(gè)體。組合為組成，整體與部分
• 關(guān)聯(lián)和依賴要注意，關(guān)聯(lián)一般為同級別有相關(guān)性，這種相關(guān)性是長期存在的。依賴為需求關(guān)系，一方需要依賴另一方，可能會因另一方的改變而改變。
• 關(guān)系的強(qiáng)弱順序：繼承=實(shí)現(xiàn)>組合>聚合>關(guān)聯(lián)>依賴

2.2 圖

2.2.1 概述

uml中的圖形非常多，按類型分為結(jié)構(gòu)圖和行為圖，其中，最常用，最典型的為9種，下面分開來介紹。

• 用例圖：從用戶角度描述系統(tǒng)功能。
• 類圖：描述系統(tǒng)中類的靜態(tài)結(jié)構(gòu)。
• 對象圖：系統(tǒng)中的多個(gè)對象在某一時(shí)刻的狀態(tài)。
• 狀態(tài)圖：是描述狀態(tài)到狀態(tài)控制流，用于表達(dá)系統(tǒng)狀態(tài)的變化
• 活動(dòng)圖：描述了業(yè)務(wù)實(shí)現(xiàn)用例的工作流程，強(qiáng)調(diào)的是動(dòng)作之間的銜接
• 序列圖：對象之間的動(dòng)態(tài)合作關(guān)系，強(qiáng)調(diào)對象發(fā)送消息的順序
• 協(xié)作圖：描述對象之間的協(xié)助關(guān)系，強(qiáng)調(diào)對象之間的合作關(guān)系
• 組件圖：描述系統(tǒng)各個(gè)組件及其相關(guān)關(guān)系的靜態(tài)視圖
• 部署圖：定義系統(tǒng)中軟硬件的物理體系結(jié)構(gòu)

2.2.2 類圖

1）說明

• 面向?qū)ο笙到y(tǒng)建模中最常用和最重要的圖，是定義其它圖的基礎(chǔ)
• 主要是用來顯示系統(tǒng)中的類、接口以及它們之間的靜態(tài)結(jié)構(gòu)和關(guān)系的一種靜態(tài)模型
• 描述細(xì)化相關(guān)的屬性和操作，是一個(gè)對業(yè)務(wù)模型面向?qū)ο蠡倪^程，也是對系統(tǒng)的約束
• 可以直接構(gòu)建可執(zhí)行代碼，但真正使用的場景相對較少

2）可用元素

• 類：

• 接口：

• 關(guān)系：可以使用上述中的6大關(guān)系。

3）實(shí)例

2.2.3 對象圖

1）說明

• 對象圖和類圖一樣反映系統(tǒng)的靜態(tài)過程，但它表達(dá)的是一個(gè)實(shí)際場景。
• 對象圖顯示某時(shí)刻對象和對象之間的關(guān)系?？煽闯梢粋€(gè)類圖的快照。
• 對象圖是類圖的實(shí)例，所以幾乎使用與類圖完全相同的標(biāo)識。

2）可用元素

• 對象：

3）關(guān)系

對象圖因?yàn)槭沁\(yùn)行在某個(gè)時(shí)間節(jié)點(diǎn)的對象鏡像，所以關(guān)系比較單一，描述的是類與類的實(shí)例之間。不涉及接口

• 關(guān)聯(lián)：對象之間存在關(guān)聯(lián)關(guān)系，如用戶和訂單
• 依賴：對象實(shí)例之間的依賴關(guān)系，如商品對象依賴店鋪

4）圖例

2）可用元素

• 組件：描述的是系統(tǒng)的其中一個(gè)組成部分，一個(gè)完整的可獨(dú)立服務(wù)的模塊或單元，比如訂單服務(wù)，k8s里的一個(gè)pod
• 部件：組件內(nèi)可能細(xì)化為多個(gè)子模塊
• 端口：組件對外提供服務(wù)就必須暴露對應(yīng)的端口。如http rest服務(wù)默認(rèn)的80
• 接口：部件/組件之間的一種約定，分提供者和需求者同時(shí)展示了某個(gè)部件提供出的功能

3）關(guān)系

• 泛化：用于接口與接口之間存在的父子關(guān)系，組件之間也可能存在，但相對用的較少
• 實(shí)現(xiàn)：接口和其實(shí)現(xiàn)者（提供服務(wù)的組件）之間
• 關(guān)聯(lián)：Require link / Connector ，接口與調(diào)用者（需要接口的組件）之間

4）圖例

2.2.5 部署圖（拓展）

1）說明

• 一種展示運(yùn)行時(shí)進(jìn)行處理的節(jié)點(diǎn)和在節(jié)點(diǎn)上存在的組件配置的圖。
• 闡述了在實(shí)際應(yīng)用中軟件和它的運(yùn)行環(huán)境的關(guān)系，并且描述了軟件部署在硬件上的具體方式。

2）可用元素

• 節(jié)點(diǎn)：

早先單實(shí)例MVC架構(gòu)下，節(jié)點(diǎn)可以認(rèn)為是某臺物理服務(wù)器，微服務(wù)及容器化下，物理服務(wù)器大多納入編排管理，docker實(shí)例由系統(tǒng)在物理節(jié)點(diǎn)見自由調(diào)度，組件無法鎖定在某個(gè)固定物理節(jié)點(diǎn)上，這種環(huán)境下的node可以理解為一個(gè)容器，或k8s中的pod。

• 組件實(shí)例

相當(dāng)于組件里的實(shí)例化，類比于類和對象

3）關(guān)系

• 依賴：發(fā)生于組件之間，如用戶組件依賴于訂單組件
• 關(guān)聯(lián)：node association，發(fā)生于節(jié)點(diǎn)之間，例如應(yīng)用服務(wù)器需要關(guān)聯(lián)mysql數(shù)據(jù)庫

4）圖例

2.2.6 用例圖

1）說明

• 用例圖是用來描述系統(tǒng)功能的技術(shù)，表示一個(gè)系統(tǒng)中用例與參與者及其關(guān)系的圖
• 主要用于需求分析階段，和產(chǎn)品文檔比較貼近
• 用例圖相當(dāng)于從用戶的視角來描述和建模整個(gè)系統(tǒng)，分析系統(tǒng)的功能與行為。

2）可用元素

• 參與者：使用系統(tǒng)的人，有多少種角色就有多少參與者。

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

3）關(guān)系

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

4）圖例

2.2.7 交互圖

交互圖分為序列圖和協(xié)作圖，兩者既可以相互轉(zhuǎn)換而不丟失信息，又存在一定差異。下面分開講再類比序列圖

1）說明

• 序列圖主要用于按照交互發(fā)生的一系列順序，顯示對象之間的消息或行為傳遞。
• 序列圖可以形象表達(dá)整個(gè)流程，和流程圖有相似之處，但是流程圖偏業(yè)務(wù)邏輯，序列圖則是系統(tǒng)面向?qū)ο蠡：?，對?yīng)到對象上的交互過程。趨向于開發(fā)者角度。

2）可用元素

• 對象：提供功能和交互的類的實(shí)例
• 參與者：同用例種的參與人，多為一段流程的發(fā)起點(diǎn)
• 時(shí)間線：對象在整個(gè)交互流程中的生命周期
• 消息：對象間需要發(fā)送和返回的消息，可以自己發(fā)給自己
• 外部參考：序列圖可以引入外部的一段作為參考，或參與序列中與當(dāng)前圖的元素交互
• 片段：將某一段序列納入片段管理，該片段像原子一樣，發(fā)生某些整體的行為，例如循環(huán)

3）關(guān)系

• 不會用到6大關(guān)系，相互之間使用message交互。代表的是信息流動(dòng)。

4）圖例

1）說明

• 協(xié)作圖與時(shí)序圖類似，二者都是用對象間的交互來描述用例的。
• 兩者關(guān)注角度稍有不同，時(shí)序圖強(qiáng)調(diào)交互的時(shí)間次序，協(xié)作圖強(qiáng)調(diào)交互的空間結(jié)構(gòu)。

2）可用元素

• 參與者：系統(tǒng)參與的角色
• 對象：同時(shí)序圖，系統(tǒng)中實(shí)例化的對象
• 關(guān)聯(lián)：對象間的關(guān)聯(lián)關(guān)系
• 消息：依附于關(guān)聯(lián)而存在，承載了對象間要傳遞的信息

3）關(guān)系

• 不會用到6大關(guān)系，相互之間使用message交互。代表的是信息流動(dòng)。

4）圖例

• 兩種交互圖可以相互轉(zhuǎn)化，類比如下：

2.2.8 狀態(tài)機(jī)（拓展）

狀態(tài)機(jī)分為狀態(tài)圖和活動(dòng)圖，

狀態(tài)圖

1）說明

• 描述一個(gè)實(shí)體基于事件反應(yīng)的動(dòng)態(tài)行為，它有兩方面的價(jià)值，一是反映對象可能有哪些狀態(tài)，二是這些狀態(tài)之間是如何流轉(zhuǎn)的，需要什么樣的條件下進(jìn)入什么樣的狀態(tài)。

2）可用元素

• 狀態(tài)：某一個(gè)時(shí)間點(diǎn)，對象所在的狀態(tài)
• 轉(zhuǎn)移：連接狀態(tài)之間，因?yàn)闋顟B(tài)時(shí)可以互相變化轉(zhuǎn)移的
• 分支/會合點(diǎn)：狀態(tài)變化中可能產(chǎn)生分叉或交會，如確認(rèn)收貨后，雙方互評產(chǎn)生分叉
• 開始/結(jié)束：狀態(tài)的起始與終結(jié)
• 同步點(diǎn)：需要多個(gè)分支狀態(tài)都具備時(shí)使用。多用于并行協(xié)作處理的狀態(tài)流轉(zhuǎn)，如互評都完成后，訂單才算終結(jié)

3）關(guān)系

• 只有轉(zhuǎn)移關(guān)系，表示狀態(tài)之間的變化

4）圖例

活動(dòng)圖

1）說明

• 活動(dòng)圖用于企業(yè)的業(yè)務(wù)流程建模，是對內(nèi)部活動(dòng)與活動(dòng)之間流轉(zhuǎn)動(dòng)作的表達(dá)
• 活動(dòng)圖類比流程圖：活動(dòng)圖存在分支與交會，可以表達(dá)并行存在的活動(dòng)，流程圖多為是與否分支判斷
• 活動(dòng)圖類比狀態(tài)圖：關(guān)注不同，狀態(tài)圖強(qiáng)調(diào)行為的結(jié)果（下一個(gè)狀態(tài)是什么），活動(dòng)圖在乎行為的動(dòng)作（下一步干什么）。兩者可以理解為穿插配合，一動(dòng)一靜，活動(dòng)可能會觸發(fā)下一步不同的狀態(tài)。

2）可用元素

• 活動(dòng)：表達(dá)系統(tǒng)中，或?qū)ο髢?nèi)的某一個(gè)可以發(fā)生的動(dòng)作
• 對象：活動(dòng)的發(fā)生者，或交互者
• 流轉(zhuǎn)：活動(dòng)的跳轉(zhuǎn)，即下一步指向誰
• 判定：類似與流程圖里的判決，根據(jù)條件產(chǎn)生不同的流轉(zhuǎn)
• 同步：并行流轉(zhuǎn)下的匯集，不同于流程圖的地方
• 起始/結(jié)束：活動(dòng)的發(fā)起與終結(jié)
• 泳道：對UML活動(dòng)圖中的活動(dòng)進(jìn)行分組，同一類活動(dòng)在一個(gè)泳道上，清晰明了

3）關(guān)系

• 只有流轉(zhuǎn)，也就是活動(dòng)的跳轉(zhuǎn)，表示下一個(gè)活動(dòng)是啥

4）圖例

3 實(shí)戰(zhàn)篇

3.1 常用工具

3.1.1 Rational Rose

老牌，大名鼎鼎，史上最有名的UML產(chǎn)品，以至于大多數(shù)情況下，很多人將他等同于UML工具，需要注意的是，自從 Rational被IBM收購之后，Rational Rose已經(jīng)成為歷史，作為UML1.4標(biāo)準(zhǔn)的產(chǎn)物，現(xiàn)在已經(jīng)不升級，但是夠用。其替代品是IBM的其他產(chǎn)品，如IBM RSA。

3.1.2 RSA

IBM? Rational? Software Architect ，IBM的旗艦產(chǎn)品，是一個(gè)高級而又全面的應(yīng)用程序設(shè)計(jì)、建模和開發(fā)工具，用于實(shí)現(xiàn)端到端的軟件交付。通過和IBM其他產(chǎn)品的協(xié)調(diào)，支持軟件開發(fā)的全生命周期開發(fā)。但是也有它的缺點(diǎn)，笨重，繁雜（大公司產(chǎn)品的通?。?？？）

3.1.3 Enterprise Architect

Sparx Systems 公司的旗艦產(chǎn)品。它覆蓋了系統(tǒng)開發(fā)的整個(gè)周期，除了開發(fā)類模型之外，還包括事務(wù)進(jìn)程分析，使用案例需求，動(dòng)態(tài)模型，組件和布局，系統(tǒng)管理，非功能需求，用戶界面設(shè)計(jì)，測試和維護(hù)等。總之你需要的基本都可以滿足，價(jià)格還便宜。性價(jià)比之選。

3.1.4 StarUML

開放源碼的UML開發(fā)工具，是由韓國公司主導(dǎo)開發(fā)出來的產(chǎn)品。用Delphi寫的，是個(gè)大神。需要付費(fèi)，網(wǎng)站提供購買注冊碼，小巧簡單而易用，與rose相比更是明顯。

3.1.5 VISIO

VISIO可以理解為一種通用的畫圖工具，它具備常見的各種圖形，從VISIO2000版本才開始涉足軟件分析設(shè)計(jì)到代碼生成的全部功能，單純從畫圖角度，有著無可比擬的優(yōu)勢，UML圖標(biāo)僅僅是其中很少的一部分。優(yōu)點(diǎn)是跟微軟的office產(chǎn)品的能夠很好兼容?？梢园褕D形直接復(fù)制或者內(nèi)嵌到WORD的文檔中。但是到代碼的生成更多是支持微軟自家的產(chǎn)品如VB，C#，ms sql 等（微軟的一貫作風(fēng)），如果僅是畫uml圖和大量的word文檔表達(dá)，它可以滿足你。

3.1.6 PowerDesigner

Sybase的企業(yè)建模和設(shè)計(jì)解決方案。采用模型驅(qū)動(dòng)方法，將業(yè)務(wù)與IT結(jié)合起來，可幫助部署有效的企業(yè)體系架構(gòu)，并為研發(fā)生命周期管理提供強(qiáng)大的分析與設(shè)計(jì)技術(shù)。將多種標(biāo)準(zhǔn)數(shù)據(jù)建模技術(shù)集成一體，并與IDE集成，典型的如Eclipse 插件形式。PD更多給人的印象是數(shù)據(jù)庫建模技術(shù)，但是它可以完成uml的所有建模操作并映射到數(shù)據(jù)庫和代碼層面。并提供60多種關(guān)系數(shù)據(jù)庫的連接支持。

3.1.7 總結(jié)

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

3.2 訂單建模實(shí)戰(zhàn)

3.2.1 B2C交易用例圖

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

1）業(yè)務(wù)需求：

• 買家：瀏覽商品，下單、支付、簽收
• 賣家：開店，確認(rèn)訂單，發(fā)貨，商品維護(hù)
• 雙方：退貨，換貨，評價(jià)，收藏

3.2.2 訂單模塊類圖

訂單類圖從業(yè)務(wù)模型出發(fā)，用面向?qū)ο笏枷?，訂單業(yè)務(wù)中的模型抽象為一個(gè)個(gè)對象

1）元素：

• 人物類：Seller，Buyer，User
• 商品類：Shop，Product
• 交易環(huán)節(jié)類：Cart，Order，Invoice，AliPay，WeichatPay，ICBCPay...
• 交易環(huán)節(jié)接口：Pay
• 促銷相關(guān)類：DiscountPromotion，ReductionPromotion...
• 促銷接口：Promotion

2）關(guān)系：

• 關(guān)聯(lián)：Order→Seller，Buyer，Pay；Shop→Seller
• 依賴：Order→Cart→Promotion，Invoice；
• 組合：Shop→Product
• 聚合：Cart→Product
• 泛化：Buyer，Seller→User
• 實(shí)現(xiàn)：DiscountPromotion，ReductionPromotion→Promotion；AliPay，WeichatPay，ICBCPay→Pay

3.2.3 訂單下單時(shí)的對象圖

對象圖表達(dá)的是下訂單的時(shí)刻，系統(tǒng)存在的對象及對象之間的關(guān)聯(lián)關(guān)系。對象具備了實(shí)際的屬性值

1）元素：

• 與類圖一致，但是接口將不復(fù)存在，而變?yōu)閷?shí)際實(shí)現(xiàn)類
• Cart生命周期終結(jié)，Invoice還沒誕生，Product，Promotion依附在了訂單上
• 對象上的屬性具備了實(shí)際值，不再是泛化的類屬性的概念

2）關(guān)系：

• 對象之間變?yōu)閷?shí)例關(guān)聯(lián)（Instance link），泛化和實(shí)現(xiàn)不再被使用。
• 弱類型可以使用依賴，比如Order與打折的Promotion

3.2.4 B2C下單支付序列圖

序列圖反應(yīng)下單到支付完成這段時(shí)間里，各個(gè)對象怎么協(xié)作和交互，互相之間需要傳遞什么消息。

1）元素

• 人物：Buyer
• 對象：Product，Cart，Order，Promotion，Pay，AliPay（外部）

2）時(shí)間序列

• 順向：Buyer→篩選→Product→添加→Cart→促銷結(jié)算→Promotion→下單→Order→支付→Pay→跳轉(zhuǎn)→AliPay
• 回路：Buyer←通知←Order←開單←Pay←回調(diào)←AliPay
• 環(huán)路：Cart ←→增刪商品

3.2.5 下單支付協(xié)作圖

協(xié)作圖同序列圖類似，可以由序列圖轉(zhuǎn)化而來。但是協(xié)作圖反映的是交互關(guān)系，像是鋪開的時(shí)序圖

1）元素，同時(shí)序圖

• 人物：Buyer
• 對象：Product，Cart，Order，Promotion，Pay，AliPay（外部）

2）交互，同序列圖

• 關(guān)聯(lián)
• 消息

3.3 總結(jié)

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

希望uml能成為你架構(gòu)工作的利器，提升效率，解決問題。Thanks！