1、UML統一建模語言定義：用於軟體系統設計與分析的語言工具目的：幫助開發人員更好的梳理邏輯、思路學習地址：UML概述_w3cschool 官網：https://www.omg.org/spec/UML 1.1、UML組成結構 flowchart TD; UML圖 --> 結構圖 & 行為圖; ...

1、UML統一建模語言

定義：用於軟體系統設計與分析的語言工具

目的：幫助開發人員更好的梳理邏輯、思路
學習地址：UML概述_w3cschool

官網：https://www.omg.org/spec/UML

1.1、UML組成結構

flowchart TD; UML圖 --> 結構圖 & 行為圖; 結構圖 --> 剖面圖 & 包圖 & 複合結構 & 對象圖 & 類圖 & 組件圖 & 部署圖行為圖 --> 交互圖 & 活動圖 & 狀態圖 & 用例圖交互圖 --> 交互概圖 & 時序圖 & 順序圖 & 通信圖

1.2、各類UML圖示例

畫圖工具可以用億圖圖示或其他工具，億圖圖示可以自行在微信訂閱號中搜索：億圖圖示V10破解即可
- 懶得找的話也可以直接去這裡：https://mp.weixin.qq.com/s/bfg_D8ADLZ7KV7PjGBEH5A

1.2.1、用例圖

定義：用來顯示一組用例、參與者以及它們之間關係的圖

是從需求分析出發，不考慮代碼實現的事，描述用戶希望如何使用一個系統。通過用例圖可以知道誰是系統相關的用戶，他們希望系統提供哪些服務，以及他們需要為系統提供什麼樣的服務

1.2.1.1、用例圖組成

名稱	含義	圖例
參與者 (Actor)	也叫角色，表示系統的用戶（在系統之外，但與系統直接交互的對象）註：這裡的用戶並不一定是指人，如：做的是公共API介面，那API的調用者就是用戶
用例 (Use Case)	描述參與者可以感受到的系統服務或者功能(換言之：描述系統為了實現用戶的目標而執行的一個系統功能單元) 註：用例的目標是要定義系統的一個行為，但並不顯示系統的內部結構 / 某個功能的具體實現
系統邊界	也叫容器(但這個名字詞不達意)，系統與系統之間的界限	兩種都對，但最常用的是矩形
子系統 (SubSystem)	一堆用例的集合，這堆用例之間有著緊密關係(換言之：展示系統的一部分功能)

1.2.1.2、用例圖之間的關係

符號	名稱	說明	圖示
`——————`	關聯	參與者與用例之間的通信（參與者和用例之間的關係）
`-------->`	包含	提取公共交互，提高復用換言之：一個用例需要某種功能，而該功能被另外一個用例定義，那麼在用例的執行過程中，就可以調用已經定義好的用例（用例與用例之間的關係）箭頭指向：指向分解出來的功能用例
	擴展	基用例保持不動，動態擴展基用例的功能（用例與用例之間的關係）擴展關係的限制規則（也是區別包含關係的手段）：將一些常規的動作放在一個基本用例中，將可選的或只在特定條件下才執行的動作放在它的擴展用例中箭頭指向：指向基用例	表示方式使用表中左邊說的那種符號或者下圖這種和包含一樣，構造型換一下也行（通常用的是下麵這種）
	泛化 / 繼承	子用例中的特殊行為都可以作為父用例中的備選流存在（用例與用例之間的關係[父子用例] ）箭頭指向：指向父用例（箭頭實心和空心都可以，嚴格來講是空心）
`<<include>>`	構造型	就是擴展的意思(UML中通用的擴展表現形式)，相當於說明 `include` 是包含關係關鍵字 `extend` 是擴展關係關鍵字

用例圖實例展示

註：下圖出鈔和憑條與退卡是說的物理機ATM保險柜的功能，並不是說出鈔和憑條與退卡是客戶從提款機中看到的這二者功能（ PS：ATM分為兩部分，一部分是我們所做的軟體系統，即：下圖的ATM系統，另一部分是ATM保險柜[錢真正在的地方]，可以說就是硬體，自動取款只是通過我們編寫的軟體系統去操作了保險柜，從而把錢吐出來）

1.2.2、活動圖

活動圖本質是流程圖，從流程圖演變而來的。

定義：對系統的動態行為建模的一種工具，描述的是活動的順序，即：從一種活動到另一種活動的控制流（本質：活動之間控制權的轉換）

對於上述我所謂的活動之間控制權的轉換的說明，如：我去進行核酸檢測（下圖不嚴謹，當流程圖來看，只是混入了活動圖的圖標在裡面）

通過下圖可以推論出：控制權不會丟失，可以分散 / 分支、最後也會合併，不會消失，只是從一個活動到了另一個活動“手裡”而已（像能量守恆一樣）

1.2.2.1、活動圖的組成

1.2.2.1.1、基本組成

名稱	定義	符號
開始狀態	表示活動開始的一個狀態註：開始狀態只能有一個	下麵兩種表示方式都可以
結束狀態	表示活動結束的一個狀態註：結束狀態可以有多個	下麵兩種都行
活動 / 動作	很多動作的集合一個動作就是一個步驟如：打籃球就是一個活動，但是：裡面卻可以有很多動作，譬如：分組、進攻、防守......當然這些還可以再細分另外：動作其實就是子圖（即：一個活動的內部邏輯。後續會說明）
狀態	和活動等價特別點：嚴格來講狀態只分為開始狀態和結束狀態，活動符號並沒有上面那種表示法（新版。舊版有），現在官網中對活動符號的表示如下：	註意：和活動符號的圖不太一樣，當然：用哪一個都可以
控制流	就是控制權的流動方向，也有人叫“轉移”	下麵兩種表示方式都可以
對象	某個類的實例或者是某些活動輸出的結果（可以理解為是一個參數，某個活動狀態需要藉助某個參數，藉助的這個參數就是一個對象）在整個活動圖中一個對象是可以多次出現的（類的實例嘛）	註意對象名稱下麵是有下劃線的另外：對象名稱註意用名詞來進行命名
對象流	可以理解為數據流就是活動與對象之間的數據傳遞，也就是活動之間需要某個 / 某些對象來參與，那麼：控制流就變成了對象流	下麵二者都可以
流終止	表示控制流 / 對象流的結束這個其實可以不要，終止了不在圖中表示出來不就表示終止了嗎
事件	可以理解為信號分為發出信號和接收信號	下圖的中間兩個，左為發出信號，右為接收信號邏輯：處理訂單後，發出請求付款的信號活動等待接收確認付款的信號活動接收到了付款信號之後，即發貨還有一種事件：叫時間事件（也可以當做是一個活動）就是等待某一個時間才能觸發某個活動時間名稱放在符號下方
判定活動	就是流程圖中的邏輯判斷	註意：這個不是分支或者合併，還差一點東西才能變成分支或合併（就是幾根控制流的線），有了這一步才能說創建分支
同步條	就是控制流（控制權）的控制下麵看到了分叉與會合之後就一清二楚了	分為水平同步和垂直同步（二者沒區別，是畫圖的方向問題，看畫的圖箭頭方向是怎樣的，然後選擇對應的同步條即可）

分支與合併（都需要判定活動參與）

分支：可以理解為控制權的分散（一個活動的控制權分給了多個活動），要求：必須是一個控制輸入流、兩個及以上的控制輸出流，符號表示方式如下(菱形+四個控制流箭頭）：
- 註意：判定活動（即：菱形）不是分支，判定活動+控制流才是分支
合併：可以理解為控制權的融合（多個活動的控制權給到了一個活動），就是分支的逆向。要求：多個控制輸入流、一個控制輸出流，符號表示如下：

分叉與會合（都需要同步條參與）

分叉：用於將一個控制流分為兩個或多個併發運行的分支，要求：必須是一個控制輸入流、兩個及以上的控制輸出流，符號表示如下：
會合：用於將兩個或多個控制流合併到一起形成一個單向的控制流，要求：多個控制輸入流、一個控制輸出流，符號表示如下：

泳道

定義：表明每個活動是由哪些對象負責完成的（換言之：表示活動的發起者是誰，對象不一定非要是人，可以是系統、會員........），也可以說是：一個對象進行了哪些活動。當然：可以換個名字就更好理解了，即：分區（一個區域中有哪些活動狀態）
泳道分類：水平泳道和垂直泳道，和前面的同步條是一樣的，水平和垂直沒什麼區別，也是畫圖方向的問題，符號表示如下：
- 實例：

子圖 / 子活動圖

在前面的表格中提到過，就是動作（活動是動作的集合體，類似Java中的對象 ---抽象---->類，很多動作 ------抽象------>活動），可以理解為：是對某個活動畫的補充圖，只不過這個補充圖是較為詳細的邏輯表現（類似一個活動需要引入的粗糙點的流程圖）
定義：對某個活動進行的續圖說明，符號表示就是一個倒著的“掃把”（下圖這種顏色的圖是我在官網下載的文檔中嫖的，版本是2.5.1）
- - 左邊活動中有一個倒著的掃把就表示這個活動要引入一個子圖，而右邊就是引入的子圖內容
註意：動作和活動這兩個不能說完全等價（鑽字眼兒），用上圖舉例：
- 如果左邊的活動裡面的一部分流程描述 / 活動組成內容剛好在另一個真正的活動圖中分毫不差地體現了，而左邊這個活動需要引入，那麼此時就可以說子圖就是活動，即：動作等價於活動
- 如果左邊的活動裡面需要的部分流程描述 / 活動組成內容沒有找到其他活動圖來完全貼合其描述，那麼就是需要新畫一個子圖來對左邊的活動進行簡略描述，繼而在左邊活動中引入，則：此時子圖是動作，而不是真正的活動，即：動作不等價於活動

擴展區域 / 擴充區 / 擴展區

定義：將一個需要體現在活動圖中的迴圈過程進行提取（不需要體現在活動圖中的，可以直接使用活動節點來略寫），有點類似於子圖，但是擴展區的關鍵就是提取的是一個活動中的迴圈過程，但不是把迴圈過程重新弄成一個活動圖，而是就在當前活動圖中
符號表示如下（左為簡單寫法，右為完整寫法）：
實例：

1.2.3、類圖、對象圖

定義（人話）：就是表示一個類 / 介面的組成結構

對於屬性：看修飾符是什麼(public、private、static等)、數據類型是什麼、屬性名叫什麼、是否有預設值

對於方法：看修飾符是什麼(public、private、static等)、返回值是什麼、方法名是什麼、參數類型和名字是什麼

..................

1.2.3.0、類圖中的標識符

關鍵字	表示方式
public	用 `+` 表示
private	用 `-` 表示
protected	用`#` 表示
package	用`~` 表示
abstract	用`*`表示
static	用 $ 表示
泛型	用`~泛型類型~`表示如：`List~int~ position`
註解	用`以<<開頭註解內容以>>結尾` 可以用一個特定的標記文本來註釋，如： `<<Interface>>` 代表一個介面 `<<abstract>>` 代表一個抽象類 `<<Service>>` 代表一個服務類 `<<enumeration>>` 代表一個枚舉
註釋	用 `%%註釋內容` 表示註釋開始到下一個換行符之前的任何文本都將被視為註釋，包括任何類圖語法這是對類圖進行註釋，即：說明，不是說屬性、方法.....都搞這個

對於類：以 https://www.processon.com 網址中的為例(下列名字見名知意，對照上面的人話定義即可)

對於介面：和上面的類圖是相通的

1.2.3.1、類圖之間的關係

名字	指向	示例	圖示
泛化 / 繼承	子類指向父類子抽象類指向父抽象類	學生類繼承人類	實心三角箭頭和空心三角箭頭都行
組合	菱形部分指向整體是屬於包含關係中的一種（組合、聚合、關聯）是`A has - a B`的關係。一句話：一榮俱榮、一毀俱毀整體和部分關係、整體部分不可分離、比聚合更強如：一個類中的一個屬性為`private Head head = new Head();` ，直接綁定在一起的	大雁和大雁翅膀的關係，兩者是同生共死的
聚合	菱形部分指向整體[箭頭指向個體，這個箭頭可有可無] 是屬於包含關係中的一種（組合、聚合、關聯）是`A has - a B`的關係。還是整體和部分的關係，但是創建時有可能是分隔開的如：一個類中的屬性為`private IDCard card;`這個屬性值可能會後續在其他地方傳進來（有參構造）	大雁和雁群之間的關係更如：電腦和主板
關聯 / 關聯類	箭頭指向成員變數類(單關聯）。這種單關聯註意一種模型圖（最嚴格的一種寫法）：在沒有箭頭的一方可能會有一個“×”，這表示：箭頭的一方一定沒有關聯“×”的一方。反之：沒有“×”表示當前模型中沒有明確說明無箭頭一方是否關聯有箭頭一方箭頭指向彼此（雙關聯），如：A類中有B類作為成員變數（屬性），B類中有A類作為屬性，此時彼此都產生關聯，即為雙向箭頭 / 雙關聯還有一種寫法：兩邊都沒有箭頭，就是一根實線，這種直接說是包含關係（是一種不嚴謹的寫法），這種直接當做屬性，A類和B類至於是單關聯還是雙關聯都行註意一種情況：下麵這種下圖不等價於上圖（它們表示“不同組”，即：上圖表示Car關聯的是駕駛這輛Car的Person，而Person駕駛的是同一輛Car；而下圖表示Car關聯的是駕駛這輛Car的Person，但Person關聯 / 駕駛的是另外的Car[某輛車需要人類中的某個人來駕駛，而人類中的另外某個人可以駕駛另外型號的車]）關聯關係是屬於包含關係中的一種（組合、聚合、關聯) 是`A has - a B`的關係是整體和部分的關係，可以分割，是後來組合在一起的換言之：兩個類之間的關聯，也可以是一個類和自身的關聯	班級類和學生類，學生類作為成員變數存在於班級類中也如：人有汽車、人有電腦
類關聯	這就是比關聯類更細節性的畫圖（讓某些情景不產生歧義）抽象了多對多的本身（A集合和B集合各自全集的笛卡爾乘積的子集）	下圖為關聯類上圖表達的邏輯：1、一個人有多條出席會議記錄，對應的是一個會議[圖符合，因為這個人可能會和不同的人開同一個會議]；2、一個會議有2或以上條出席會議記錄，對應的是一個人[圖也符合，因為這個會議某個人可能參加了多次]。所以雖然圖看起來沒問題，但是不貼合現實[一個人出席了同一個會議那記錄為1就可以了，按上圖來看就會出現某個人有多條出席會議記錄 - 即：重覆了]，所以上圖中“總的出席會議記錄數量大小”在數學上應該是：多人、多會議各自全集的笛卡爾乘積的子集[會排除重覆的]，因此為了貼合現實圖就改造為如下的類關聯：邏輯：1、2或以上的人對應多個會議（多對多)；2、出席會議記錄類關聯了人和會議兩個類，並且出席會議記錄最後的結果為兩邊集合各自的全集的笛卡爾乘積的子集[排除重覆的結果])
依賴	箭頭指向入參類 `A need - a B` 的關係	班級類和學生類，班級類作為學生類的方法入參
實現	箭頭指向介面	學生類實現人類

1.2.3.1.1、各類圖關係實例

1.2.3.1.1.1、泛化 / 繼承

public class DaoSupport{

    private String name;

    public void save(Object entity){}

    public void delete(Object id){} 
}


public class PersonServiceBean extends Daosupport{
}

使用typora的mermaid腳本畫圖

語法：
<|-- 表示繼承 箭頭指向的一方是被繼承者

+ 表示 public

- 表示 private

語法學習地址：Markdown教程-慕課網 (imooc.com)
mermaid語法學習地址：https://mermaid-js.github.io/mermaid/#/


```mermaid

    classDiagram
    %% 要用註釋只能放在這裡，對類圖進行說明
        class DaoSupport{
			屬性返回值類型放在前面 -String的-和String中間最好也別搞空格(只是這個mermaid腳本中而已)，但是嚴格寫法應該是 -name : String
			-String name
			方法返回值類型是在後面 另外：+void的+和void之間別搞空格
            +save(Object entity) void
            +delete(Object id) void
        }

        class PersonServiceBean{

        }

        DaoSupport <|-- PersonServiceBean
```

效果如下：

classDiagram %% 這是一個小試牛刀的類圖 class DaoSupport{ -String name +save(Object entity) String +delete(Object id) void } class PersonServiceBean{ } DaoSupport <|-- PersonServiceBean

1.2.3.1.1.2、組合


public class Person {

    // 組合關係：某個類的對象 當做 當前類的屬性，並已經new了
    private Head head = new Head();
}

mermaid腳本畫圖語法：

*-- 表示組合，星* 指向的是整體即：菱形指向整體

```mermaid

    classDiagram

        class Person{

        }

        Person *-- Head  // 表示的是：Person 組合 Head
```

效果如下：

classDiagram class Person{ } Person *-- Head

1.2.3.1.1.3、聚合

public class Person {
    // 聚合關係
    private IDCard card;
    
    // 對照：組合關係
    private Head head = new Head();
}

```mermaid

classDiagram
	class Person{
	
	}
	
	Person o-- IDCard  // 這是字母o 不是0，菱形指向整體 即：Person聚合了IDCard

```

效果如下：

classDiagram class Person{ } Person o-- IDCard

1.2.3.1.1.4、關聯、依賴、實現

1.2.3.2、對象圖

定義：表示在某時刻對象和對象之間的關係(由於對象存在生命周期，因此對象圖只能在系統某一時間段存在)
對象圖是類圖的實例，幾乎使用與類圖完全相同的標識。一個對象圖可看成一個類圖的特殊用例

1.2.4、順序圖(時序圖 / 序列圖)和通信圖

1.2.4.1、順序圖

定義：用來表達對象間消息傳遞的順序

一般來說：順序圖也叫時序圖、序列圖（這三個在英文中都是Sequence ），但是：嚴格來說（電子通訊方面），順序圖是順序圖，時序圖 / 序列圖是時序圖 / 序列圖（在電子通訊方面，這個實在要對應的話，就對應UML中的時間圖Timing Diagram），在電子通訊領域這二者要表達的意思並不一樣，但是對於我們編程這一行業來說：直接把順序圖、時序圖、序列圖等價也沒錯，叫其中哪一個名字都無所謂

1.2.4.2、順序圖組成

markdown中畫時序圖語法（本質是使用了mermaid腳本）：https://www.imooc.com/wiki/markdownlesson/markdownsequencediagram.html
mermaid腳本語法：https://mermaid-js.github.io/mermaid/#/sequenceDiagram

名稱	說明	圖示
參與者	也叫角色，表示系統的用戶（在系統之外，但與系統直接交互的對象）註：這裡的用戶並不一定是指人，如：做的是公共API介面，那API的調用者就是用戶
對象	就是對象圖中的對象，可理解成某個類的實例	如果只顯示類名，則：去掉上圖中“對象名”即可，即： `:某個類類型` 如果只顯示對象名而不顯示類名，則：去掉 `:` 及之後的即可，即: `對象名`
生命線	表示對象的生存時間（就是一條向下的虛線）
激活	表示某種行為的開始或結束，就是一個小矩形反之：沒有小矩形的那些虛線就是對象的休眠
消息	分為同步消息和非同步消息在UML中，指的是：對象與對象之間的通信在順序圖中是用兩個對象之間帶箭頭的線來表示	註：下圖真實含義是另一個，拆開看，單獨只看兩個帶箭頭的線即可，整個圖的場景是另一個意思帶實心箭頭的實線：發送消息 / 方法調用帶開放式的三角箭頭的虛線：返回消息 / 返回值（特別需要返回消息時就用，不特別需要的話，那麼採用下麵同步那種簡化畫法就可以了)
同步消息	就是消息發送完畢了，就返回消息（一條龍服務）當然：這也意味著阻塞和等待	當然：上圖也可以換成前面那種用“開放式的三角箭頭的虛線返回消息”，上圖這種是簡寫形式註意：1、圖中參數哪裡要是沒有，不表示就沒有消息的發送（調用方法，方法本身就是消息發送)；2、如果沒有返回值，即：`void`那也不表示沒有返回消息（當進行方法調用時，右邊已經激活，一樣會進行阻塞，即：右邊激活條做完該做的事情，照樣給左邊返回信息，告知調用者事情做完了，只是圖中不會顯示地畫出來而已，但內部邏輯還是有的)
非同步消息	和同步換一下，就是消息發送完畢了，返回消息可以後面給（中間可以做完另外的事情再給）同理：這就意味著非阻塞	註意：和同步消息畫法不一樣（箭頭不一樣)，另外：非同步中返回消息不是虛線，是實線（就是變成右邊對象向左邊對象發送消息：內容就是左邊對象要的返回消息 / 返回值)
持續消息時間	字面意思出現的情況：有些消息需要持續很長一段時間，從而需要標註出來（如：大文件上傳）	第一種：使用帶有實心箭頭的傾斜的線表示（下圖 `{}` 中括弧中是條件控制，在後續會介紹）第二種：表達準確的時間（在第一種的基礎上，繼續加入東西) 上圖表示：在2h內上傳文件，然後返回結果之後等待5min以上，檢查上傳情況
重入消息	A對象給B對象發消息，在B還未返回消息之前，B給A發了一條消息
自我調用	是重入消息的特例（A給B發消息，在B未返回之前，A又給自己發了一條消息）所以就是自己玩自己（俗稱：自wei）	下麵兩種畫法都可以(嚴格來講是第一種）
無觸發和無接收消息	上面那些都是基於系統本身內部的，但是：有些可能需要使用到系統外部的某些東西（對象、參與者....）在技術實施開發層面一般不會見到，其他崗位會有
對象的創建	字面意思	被創建對象會比生命線矮一截（就是下圖中右邊比左邊矮一點）
對象的銷毀	字面意思，表示方式就是在對象銷毀時打一個“×”

1.2.4.3、執行控制

關鍵字	說明
alt	備用多個片段：只執行條件為真的片段（就是條件分支`if else`）
opt	可選項：僅當提供的條件為真時才執行片段。相當於只有一條痕跡線的alt
par	並行：每個片段並行運行
loop	迴圈：片段可以執行多次，並且防護指示迭代的基礎
region	關鍵區域：片段只能有一個線程一次執行它
neg	否定：片段顯示無效的交互
ref	參考：指在另一個圖中定義的交互，繪製框架以覆蓋交互中涉及的生命線（可以定義參數和返回值）
sd	序列圖：用於包圍整個序列圖

上面的都是官方話，接下來舉一些常用的例子。

1.2.4.3.1、條件分支 alt

1.2.4.3.2、可選項 opt

包含一個可能發生或不發生的序列

只要當我成績score小於60時，老媽打我這件事情肯定會發生。大於就不會發生

1.2.4.3.3、迴圈 loop

圖是網上偷的，看懂了分支，那迴圈也能很容易看懂了

1.2.4.3.4、並行 par

1.2.4.4、順序圖實例

SpringMVC執行流程原理

轉化為順序圖

1.2.4.5、通信圖

通信圖和順序圖可以等價互轉
通信圖犧牲了順序上的直觀性，增強了佈局和關聯上的直觀性；而順序圖是相反的
要搞邏輯就看序號（1:、1.1:、2:、2.1:..........）
假如一個序列圖如下：

轉化為通信圖（兩張圖對照看就懂了）：

1.2.5、狀態圖 / 狀態機圖 / 轉移圖

定義：狀態圖又名狀態機圖或轉移圖，指的是：一個特定對象的所有可能的狀態以及引起狀態轉換的事件
一個對象必然會經歷一個從開始創建到最終消亡的完整過程，這稱之為對象的生命周期。對象在其生命周期內是不可能完全孤立的，它必然會接受消息來改變自身，或者發送消息來影響其他對象。而狀態機就是用於說明對象在其生命周期中響應時間所經歷的狀態序列以及其對這些事件的響應。在狀態機的語境中，一個事件就是一次激發的產生，每個激發都可以觸發一個狀態轉換

1.2.5.1、狀態圖的組成

一份簡單的狀態圖

狀態圖組成

名稱	說明
狀態	指的是對象在其生命周期中的一種狀況，處於某個特定狀態中的對象必然會滿足某些條件、執行某些動作或者是等待某些事件
動作	指的是狀態機中可以執行的哪些原子操作原子操作：指的是他們在運行的過程中不能被其他消息中斷，必須一直執行下去，以至最終導致狀態的變更或者返回一個值
事件	指的是發生在時間和空間上對狀態機來講有意義的那些事情事件通常會引起狀態的變遷，促使狀態機從一種狀態切換到另一種狀態
活動	指的是狀態機中做的那些非原子操作
轉移	指的是兩個不同狀態之間的一種關係，表明對象在第一個狀態中執行一定的動作，並且在滿足某個特定條件下由某個事件觸發進入第二個狀態

1.2.5.2、狀態圖的五要素

註意：

上圖中“觸發事件”和“監護條件”要同時生效的，即：只有“觸發事件”滿足“監護條件”，才能執行“動作”，從而讓第一個狀態轉移為第二個狀態
- “監護條件”寫法就是[監護條件]，[]不能丟
上圖中整個“帶箭頭的三角的實線（單純地這根線）”就是“轉移”，或者稱之為：行為狀態也行
上圖中整個“帶箭頭的三角的實線+上面的觸發事件[監護條件]/動作”就是事件，其中：觸發事件[監護條件]/動作三者少哪一個都行，甚至全沒有也行

1.2.5.3、狀態圖中的狀態

註：初態和終態都不是真正的狀態，而是：偽狀態

名字	說明	圖示
初態	一個狀態圖有且只有一個初態	黑色實心
終態	一個狀態圖中可以有一個或多個終態，也可以沒有終態	一對同心圓（內圓為實心圓）
中間態	用圓角矩形表示，可以用一條水平橫線把它分成上、下兩部分。（上面部分為狀態的名稱[必有]；下面部分是活動表[可選]）有些軟體是分成了三部分：上面部分為狀態的名稱（必有）；中間部分為狀態變數的名字和值（可選）；下面部分是活動表（可選）
子狀態	就是狀態中套狀態
歷史狀態	就是一個對象曾經已經發生過的狀態的記錄，類似歷史日誌作用：用來恢復狀態的。如：斷電了，導致系統整個狀態結束了，恢覆電之後想要回到斷電時的狀態就可以用	可以多層嵌套，就是一個套一個（有可能要恢復的狀態在很多層裡面）舉例：

對於上面表格的中間態中說的活動表的說明：

活動表又名轉換域
表達式語法為：事件名(參數表)/動作表達式，其中：參數表也可以沒有，如下：
在活動表中經常使用的3種標準事件
- do 上圖已經見過了，指的是：在該狀態下的動作
- entry 進入該狀態的動作
- exit 退出該狀態的動作

1.2.6、組件圖 / 構件圖

定義：用來描述一個系統 / 功能的物理構件( 組件與組件之間的關係 )。包括文件，可執行文件，庫等。換言之：構成系統某一特定方面的實現結構
組件圖 = 構件 / 組件（Component）+介面（Interface）+關係（Relationship）+埠（Port）+連接器（Connector）

1.2.6.1、組件圖的組成

1.2.6.1.1、組件

定義：是一個封裝好的物理實現單元，隱藏內部的實現，對外提供了一組介面
具有自己的身份標示和定義明確的介面。由於它對介面的實現過程與外部元素獨立，所以組件具有可替換性

人話：組件就是一個實際的文件或者多個文件組成的可執行程式（通俗的話來說[嚴格來講不能這麼理解，但是為了理解而理解，可以用]：組件就相當於Java的抽象和封裝思想（當然：懂Vue的話，那就懂組件化開發了，那就更不用解釋了）

組件的種類：

源代碼組件：一個源代碼文件或者與一個包對應的若幹個源代碼文件
二進位組件：一個目標碼文件，一個靜態的或者動態的庫文件
可執行組件：在一臺處理器上可運行的一個可執行的程式單位，即所謂的可執行程式

組件長什麼樣子(UML1.x的畫法）

1.2.6.1.2、組件盒(就是組件)

定義：就是一個用來裝組件的盒子

當然：組件盒其實就是組件，這二者就是等價的，因為這盒子裡面裝的就是組件，因此：UML2.x中，組件就是組件盒

組件盒長什麼樣子

因此：組件的畫法就可以弄成下麵幾種了

矩形+圖標
矩形+構造型標簽，就是上面組件盒的畫法，下圖構造型標簽<<>>中寫組件中文名字也行（但：建議用英文關鍵字）
前面兩者都有的畫法，這種畫法構造型標簽<<component>>就只起到標識作用

1.2.6.1.3、介面

分為兩類：提供介面和需求介面

提供介面：又被稱為導出介面或供給介面，由提供操作的組件提供，是組件為其他組件提供服務的操作的集合（如：商品組件提供商品相關的一堆介面）
需求介面：又被稱為引入介面，是組件向其他組件請求相應服務時的介面（訂單組件需要調用商品組件提供的介面）

提供介面長什麼樣子？

需求介面長什麼樣子？

1.2.6.1.4、埠

這個已經在熟悉不過了
就是一個被封裝的組件的對外視窗
在封裝的組件中，所有出入組件的交互都要通過埠。它是被封裝的組件與外界的交互點，遵循指定介面的組件通過它來收發消息
表示方式：就是一個小矩形

1.2.6.1.5、連接器

指的就是組件間的連接，換言之：就是組件之間的關係，也就是在類圖中的實線、泛化關係........等等，所以：連接器不只是在組件圖中，在UML圖中都有，就是那些線嘛（在組件圖中，這種關係有個專業名詞叫：組裝連接器，還有一個委托連接器：連接外部介面的埠和內部介面[這個不需要多瞭解]）
- 實現關係：用直線表示
- 依賴關係：用帶箭頭的虛線表示
額外補充：組件依賴的表示方式
- 上圖中上面那種也叫插座表示法，和下麵的表示方式是等價的

1.2.6.1.6、前幾者組合在一起的樣子

外面大的那個就是容器，和包圖很像（但不太一樣）

既然提到了包圖，那就一次性弄完：

包圖：見名知意。和平時接觸的包依賴關係一樣。如：A包導入B包，那A包可以使用B包的東西
- 單個包圖完整樣子是下麵這個鬼樣

搞到了包圖，那就解釋一下前面連接器那裡：為什麼連接器是通用的問題

為什麼連接器可以通用？有個包關係是如下的樣子
- 即：混合結構(Composite Structures)中導入了類圖(classes)，後面的依次看，繼而推出：混合結構(Composite Structures) 是類圖(classes)的一種擴展，同理：組件圖中就有了混合結構和類

1.2.6.1.7、混合結構

上面提到了混合結構，那也來搞一下

混合結構的意思就是字面意思，混合嘛，即：類圖、組件圖......混合使用（開發中的那個畫法就是）

解讀：
- 整個Car大框就是類圖，類圖中的屬性（Car下麵的那個屬性的大框）變成了組件圖（組件圖中再套組件圖.......），組件圖中的屬性表示方式和類圖中一樣（-為private、+為public，屬性名、屬性類型.....）

1.2.6.1.8、組件圖示例

在網上嫖的圖，意思意思

1.2.7、部署圖

定義：描述的就是物理層面的模型，就是讓系統和硬體打上交道

部署圖與組件圖相同的構成元素：

組件、介面、組件實例，提供介面（組件向外提供服務）、需求介面（組件要求外部提供的服務）

部署圖與構件圖的關係：

部署圖表現組件實例；組件圖表現組件類型的定義

部署圖偏向於描述組件在節點中運行時的狀態，描述了組件運行的環境

組件圖偏向於描述組件之間相互依賴支持的基本關係

上面提到了組件和組件實例，其實只是不同的稱呼而已，在組件圖中都已經見過，只是換成部署圖中名字有細微區別而已，符號都是一樣的

1.2.7.1、部署圖的組成

1.2.7.1.1、物件 / 構建 / 組件

定義：就是被部署的東西

長什麼樣子在組件圖中已經見過了（參考：1.2.6.1.1、組件）

1.2.7.1.2、節點

定義：運行時對象和組件實例駐留的位置（把方向放大一點：也可以說是物件要部署的目標位置，即：物件要部署到哪裡去）

節點畫法：

針對於各對象 / 各節點的部署來說：描述的各節點之間的關係（也叫實例層部署）

1、前面玩過的那些類圖、對象圖、組件圖中的關係都可以用，部署圖就看部署的是什麼
- 各對象關係部署（就是對象圖簡化版，換個意思，換個場景[部署]，細微換一下畫法罷了），支持：一對多、多對多
  - 官方文檔中是這樣介紹這種部署的
2、各節點關係部署，支持：一對多、多對多
- 再加一點東西就變成官方文檔中說的：節點實例部署，支持：一對多、多對多

針對節點以及其包含的組件的部署（這種也叫描述層部署），官方文檔稱之為：組件 / 工件部署（工件：指的是任何留下記錄的事物都可以稱之為工件），叫法無所謂，支持：一對多、多對多

1.2.7.1.3、物件與結點的關係：部署

就是下圖中組件和整個節點的關係（deploy）

如官方文檔中

1.2.7.1.4、結點與結點的關係：通信路徑

指的就是下圖中的那根線+通信方式

2、設計原則

單一職責（Single Responsibility Principle）：一個類和方法只做一件事（有且僅有一個原因引起它的[類和介面]改變）

開閉原則（Open Closed Principle）：抽象架構，擴展實現

里氏替換（Liskov Substitution Principle）：多態，子類可以擴展父類

迪米特原則（Law of Demeter）：最少知道，降低藕合

介面隔離（Interface Segregation Principle）：建立單一介面 / 介面不可再分

依賴倒置（Dependence Inversion Principle）：細節依賴抽象，下層依賴上層（也可以叫做面向介面編程）

以上幾個的第一個單詞首字母合起來就是（里氏替換原則和迪米特法則的首字母重覆，只取一個）： SOLID（堅硬的）

2.1、單一職責原則

定義：一個類和方法只做一件事（有且僅有一個原因引起它的[類和介面]改變）

如打電話分為：撥通、交流、掛斷，類圖如下

但是這樣是有問題的，因為：dial撥通、hangup掛斷是屬於鏈接管理，而chat交流是屬於數據傳送，所以這個IPhone介面就有兩個原因導致它發生變化了，因此：進行改造，抽離（面向介面編程，對外公佈介面，不公佈實現類）

2.2、開閉原則

定義：抽象架構，擴展實現

具體意思：指一個軟體實體如類、模塊和函數應該對擴展開放，對修改關閉。也就是說一個軟體實體應該通過擴展來實現變化，而不是通過修改已有的代碼來實現變化

如書店賣書，類圖如下：

- 接下來搞打折活動，這時不可能說是去修改IBook介面，在裡面新增一個打折getOffPrice()的方法吧，這樣的話，那實現類NovelBook需要改源碼，而關聯類BookStroe也需要修改。甚至也不可能直接在實現類NovelBook中把getPrice()的邏輯進行修改，這兩個方法都不行，因此：應該改成如下的樣子
  - 重新來一個OffNovelBook類繼承NovelBook，從而重寫getPrice()方法，這樣就做到：對擴展開放[原價格可以在NovelBook類的getPrice()中拿到，打折後的價格可以在擴展類OffNovelBook的getPrice()方法中拿到]、對修改關閉[並不需要動原有的代碼]

2.3、里氏替換原則

定義：多態，子類可以擴展父類（所以得知：針對的是繼承）

里氏替換原則通俗易懂的定義是：只要父類能出現的地方，子類就可以出現，而且替換為子類也不會產生任何錯誤或異常（在開發中的場景是：定義一個介面或抽象類，然後在使用其實現類時，傳入介面類型的參數，即：多態），但是：又包含4層含義

1、子類必須完全實現父類的方法

2、子類可以有自己的屬性和方法

3. 覆蓋或

UML建模、設計原則、設計模式（創建型）

1、UML統一建模語言

1.1、UML組成結構

1.2、各類UML圖示例

1.2.1、用例圖

1.2.1.1、用例圖組成

1.2.1.2、用例圖之間的關係

1.2.2、活動圖

1.2.2.1、活動圖的組成

1.2.2.1.1、基本組成

1.2.3、類圖、對象圖

1.2.3.0、類圖中的標識符

1.2.3.1、類圖之間的關係

1.2.3.1.1、各類圖關係實例

1.2.3.1.1.1、泛化 / 繼承

1.2.3.1.1.2、組合

1.2.3.1.1.3、聚合

1.2.3.1.1.4、關聯、依賴、實現

1.2.3.2、對象圖

1.2.4、順序圖(時序圖 / 序列圖)和通信圖

1.2.4.1、順序圖

1.2.4.2、順序圖組成

1.2.4.3、執行控制

1.2.4.3.1、條件分支 alt

1.2.4.3.2、可選項 opt

1.2.4.3.3、迴圈 loop

1.2.4.3.4、並行 par

1.2.4.4、順序圖實例

1.2.4.5、通信圖

1.2.5、狀態圖 / 狀態機圖 / 轉移圖

1.2.5.1、狀態圖的組成

1.2.5.2、狀態圖的五要素

1.2.5.3、狀態圖中的狀態

1.2.6、組件圖 / 構件圖

1.2.6.1、組件圖的組成

1.2.6.1.1、組件

1.2.6.1.2、組件盒(就是組件)

1.2.6.1.3、介面

1.2.6.1.4、埠

1.2.6.1.5、連接器

1.2.6.1.6、前幾者組合在一起的樣子

1.2.6.1.7、混合結構

1.2.6.1.8、組件圖示例

1.2.7、部署圖

1.2.7.1、部署圖的組成

1.2.7.1.1、物件 / 構建 / 組件

1.2.7.1.2、節點

1.2.7.1.3、物件與結點的關係：部署

1.2.7.1.4、結點與結點的關係：通信路徑

2、設計原則

2.1、單一職責原則

2.2、開閉原則

2.3、里氏替換原則