StarUML中的活動圖本質上是流程圖，活動圖相對來說，更加專業，它有對信號的處理，對狀態動作、數據區別表示，使得更清晰地了解控制流的走向。
1、基本元素
a、活動狀態圖(Activity)、動作狀態(Actions)
活動和動作使用同一個圖表示，活動狀態與狀態機的狀態是同一個意思，代表着一種狀態，它是由別的狀態流轉而來，也可以流轉到別的狀態，同時也可以自流轉，流轉到自己；動作狀態代表的就是一個動作。
活動狀態圖，是可以細化的，所以有時候會先畫一個大的活動狀態圖，然后將該活動暴露的接口和所使用到的接口都在這個圖里標識好，然后再在這個活動圖里細化相應的邏輯。
內部填充具體的支付系統邏輯，更詳細的案例，見文末案例e。
b、動作流(Control Flow)
即動作之間的轉化，由一根連線將兩個動作狀態圖連接起來。
c、開始節點(Initial)
即活動開始的節點。
d、終止節點(Final nodes)
終止節點分為活動終止節點和流程終止節點；
活動終止節點，代表着整個活動結束了，不會有其他的分支在跑。
流程終止節點，代表着某個流程結束了，其他流程還在跑，整個活動還沒有終止。
e、對象(object)
對象屬於數據流的一部分，用矩形框表示。
f、數據存儲對象(DataStore)
使用關鍵字<<datastore>>。
g、對象流(Object Flow)
對象流實際上是控制流中插入對象，以表達對象、動作和狀態之間的關系。
具有以下特征：
(1) 一個對象可以由對個動作操作；
(2) 一個動作輸出的對象可以作為另一個動作的輸入對象；
(3) 在活動圖中，一個對象可以出現多次，它的每一次出現代表着對象分處於生命周期的不同狀態。
對象流中的對象名稱分為兩部分，一部分是對象名，下面是對象的狀態，如果一個對象不存在多個狀態，那么下面的狀態表示可以去除掉。(暫時不知道怎么將狀態寫到下面，只能寫在右邊)
h、分支和合並（Decision Merge）
分支和合並公用一個圖形，該圖形有多個出口也有多個入口，每個出口都用對應的條件標識，類似於編碼中的if else 或者 switch case，每個分支都是條件的。
i、分叉和匯合(Fork Join)
分叉和匯合與分支和合並類似，但有本質區別，否則是狀態流轉與條件掛鈎，一次只能走一條路，但是分叉和匯合則是並行的，每次每條路都要走，它表示的不是說多條路選一條的意思，而是多條路要同時走。
分支和分叉因為前者入口都標有條件而后者沒有標，所以容易區分，但是合並和匯合非常類似，入口都是沒有條件的，區分的方法就是 所有入口是不是相斥的，如果是就是合並，后者就是匯合。
j、信號（Signal）
信號分為兩種，一種是接收信號，一種是發出信號，還有一種比較特殊，時間事件，有的地方也把這個叫做時間信號
時間信號，本質上是在表示一種時間動作，一般是表示等待
接收信號大部分情況下不用畫，直接由發出信號指向活動或者動作圖。
2、泳道
泳道圖出自 跨職能圖，每個泳道代表着不同的組織、系統或者是個人，泳道里的圖代表着該組織所負責的邏輯，在活動圖里也是一樣，在信號部分，就用到了泳道。
3、案例
a、購物用例圖
b、 帶有發送信號與接收信號的活動圖
這個案例中，左上角用的是匯合，用錯了，應該采用合並，因為有空位和沒有空位是相斥的，才能采用合並。
c、帶對象流的活動圖
d、輔助活動圖
e、典型案例
畫得好的圖，圖在兼顧清晰明了的基礎之上，盡量讓圖更加緊湊些。
本文學習對象：https://www.cnblogs.com/xiaolongbao-lzh/p/4591953.html