今天要介紹的是活動圖(Activity Diagram)。
活動圖主要是一系列的程序顯示出來，在這些程序中包含了系統要做的事情，也可以包含非系統做的事情。當然，主要的目的還是為了溝通，所以還是以不要將活動圖繪製得太複雜為原則。

首先先來介紹下列圖形的說明：


活動節點（Action node）：根據UML裡的定義是說：『An activity node is an abstract class for points in the flow of an activity connected by edges.』看起來似乎有點複雜，可是，在看過例子之後就會覺得其實沒那麼複雜。因為每一個節點就是可以看做一個事件，例如：下訂單、申請成績單…等。

物件節點（Object node）：一般來說我是比較少看到有人用，可能我用的不多吧！物件節點與活動節點最大的差別就是，活動節的是不攜帶任何資料的，而物件節點是有攜帶資料，這個稍後我們可以從範例中可以很清楚的看出來。

控制節點(Control Node)的圖形如下：



啟始節點(Initial node)：每一張活動圖一定要有一個開始的地方，而這個地方就是叫做啟始節點(Initial node)。

在UML中有兩種終止節點(Final nodes)：活動終止(Activity final)及流程終止(flow final)。而這兩種分別代表不同的終止意思。

Activity final代表的是整個Activity Diagram的流程終止。
Flow final代表的是Activity Diagram的分支流程終止，這時候如果有其他流程在跑，則不會受到該分支流程終止的影響。

Merge node(合併節點)與Decision node(判斷節點): 顧名思義，就是合併不同分支及判斷流程(flow)該往那個分支的意思。

控制流成(Control flow)與物件流程(Object flow)最大的差別就是在，控制流程無發攜帶任何資料或物件給下一個流程，而物件流程可以攜帶資料或物件。





從上方兩個圖就可以看出，活動節點(activity node)與活動節點之間一定是控制流程(Control flow)，而活動節點與物件節點(object node)之間就是物件流程(object low)。



http://ithelp.ithome.com.tw/question/10103368

前言UML本來就無絕對的對錯，以草稿的用途來說，UML只是拿來溝通的一種標準工具。

雖說UML無絕對的對錯，但是每一張Diagram上的element卻是有它一定的意義，這是不能隨意更改的。
就像跟人家溝通的時候，你沒法子說，在我寫的程式裡面True代表False，False代表Null，Null代表True一樣。
(因為全世界只有你自己這樣用，你要跟誰溝通呢？)

所以，當你說出，UML只要可以溝通就好，不必侷限在圖怎麼畫，
我想說的是，用圖來表達，絕對比用文字或是言語說明來的清楚的多。
UML也的確沒有對錯，
但是請不要濫用、誤用別人標準上的Element，還稱自己的diagram為UML diagram，
那樣只會笑掉人家的大牙，也會讓人覺得你不夠Professional。

當瞭解前面的前提後，
這篇文章的內容，是在上週要幫公司新人training時準備的簡略教材，
讓PGR明白，看的懂哪一些UML diagram後，對他們在撰寫程式、與各層級溝通上，是有很大的幫助的。
(不期望也不需要，PGR拿UML來分析系統，那是SA該做的事。所以PGR可以不會畫，
但是應該要看的懂這些圖，才能在動手寫code之前，do the right thing，而不是do the wrong thing right)

What UML Diagrams You Should Know?

1. Use Case Diagram  
   
   可以幫助PGR瞭解自己正在寫的系統到底是什麼，
   系統範圍有多大，
   有多少相關外部界接系統，
   有多少角色會使用這樣的系統，
   系統要提供什麼樣的角色使用什麼樣的功能。
   反思自己正要進行的規格功能設計，是屬於那一塊Use Case。
2. Activity Diagram  
   
   通常是SA會先請User提供現行的作業流程文件，
   再來進行企業流程分析，畫出Activity Diagram，有點類似flow chart，但是主要focus的目標在每一個activity。
   
   PGR瞭解各個抽象等級的activity diagram，有助於知道自己正在進行的功能，
   在Use Case Diagram裡面是屬於哪個Use Case，而該Use Case裡可能有很多Activity，可以幫助瞭解前後支程式的關聯與走向。
   
   在開始動手寫程式之前，瞭解系統的前後關聯功能，傳遞參數等，
   可以避免這支程式寫完單元測試可能通過，系統整合測試卻有一大堆問題(例如寫死測試值)。
3. State Machine Diagram
   這也是抽象層級可大可小的UML diagram，不過這張圖對PGR應該比較不陌生，
   也是類似flow chart，但是focus的目標在於「狀態的改變」。
   
   PGR如果瞭解這張圖，在看到規格上展開所有UI的prototype時，
   才不會手忙腳亂，不知道什麼時候該做什麼事。
   
   這張圖對設計UI動線很有幫助。
4. Class Diagram  
   
   這邊的Class Diagram指的並非是從一堆class code 逆向工程gen出來的圖，
   而是還沒寫CODE之前，SA與SD設計的圖。
   
   Class Diagram可能很大，因為它mapping到的可能是某個Use Case，
   PGR要瞭解自己正在進行的功能，是整張Class Diagram的哪一個區塊，
   自己功能內相關的有哪一些class，class彼此之間的關係等等。
   
   可以供PGR在開始寫程式之前，就知道要使用哪一些Class (mapping到系統架構可能是BLL的Service跟Domain object)。
5. Sequence Diagram
6. 這張圖就更細了，最適合PGR看的一張圖，
   因為就跟trace程式一樣，可以知道哪一些物件什麼時候要被初始化，
   物件與物件之間如何互動，該傳遞與回傳什麼樣的訊息，
   搭配state machine diagram去進行condition的判斷，
   搭配class diagram去完成物件與物件之間的互動。
   
   這張圖其實很適合擺在程式規格裡面，用來描述PGR在進行這支功能設計時， 該有的logic flow。

http://www.dotblogs.com.tw/hatelove/archive/2009/10/21/11183.aspx

[修練營 UML]簡介軟體開發相關角色與UML產出模組
前言一個中大型軟體系統開發，系統工時往往超過24個人月，
其中每個系統開發階段，相關的角色與應有的產出，產出的文件與其他角色和每個階段的關係都是環環相扣的。

這邊透過EA的Sample Project來簡介一下，軟體開發會有哪一些階段、相關的角色、相關的產出文件。

說明我們先從一張Overview的概觀圖來看，可以看出軟體開發時，可以被分成以下幾類Model：


接著我們在根據軟體開發順序去看相關的角色應該負責哪一些Model文件的產出：

UML的精神，就是一張圖抵的上千言萬語，
其實圖上的說明已經很清楚了，這邊為了避免有騙讀者的嫌疑，就幫忙多補充一些相關敘述。

1. Business Model階段
   • 主要由Business Analyst負責
   • 分析企業流程與領域模型
   • 產出相關的文件應有Process Model與Domain Model
     • Process Model的範例
     • Domain Model的範例

Requirements階段(屬Requirements Model)

• 主要也是由Business Analyst負責
• 界定出User的需求，每個需求給定一個REQ編號，依據不同類型切成不同模組
• 產出相關的文件可以分成Formal Requirements與Non-Functional Requirements Model，不同需求之間可能也會存在著relation
  • Formal Requirements
    • Take Orders Requirement之間的關係
  • Non-Functional Requirements Model
    • Security Requirement之間的關係

Use Cases階段(屬Requirements Model)

• 主要由Use Case Modeller負責產出Use Case Model，Architect則負責描繪出至少符合Requirements與Use Case的System Model
• Use Case Diagram
• System Model裡面則包含了相當多的模組，在PIM階段，還沒到PSM之前，這些文件都與實作的語言和平台無關，這樣才符合MDA的規範，
  也才能讓系統分析和領域模型趨於穩定

Analysis階段(屬System Model)

• 主要由System Analyst負責
• 產出Analysis相關文件，例如
  • Communication Diagram
  • State Machine Diagram

Design階段(仍屬System Model)

• 由Developers與DBA負責
• 產出User interface、Abstract Class Model(PIM部分)，再由PIM的部分產出屬於PSM的部分，例如DDL與C# Model，DDL則由DBA維護與監管
  • 整個Design Model的關係
    • User Interface(也就是UI畫面)
    • Abstract Class Model
    • C# Model
    • DDL(Data Model)

Deployment階段(仍屬System Model裡)

• 主要由Developers負責
• 所有與部屬相關的文件，例如Server的機器規格、Client端的OS、網路相關資訊
  
• Component Diagram

結論雖然台灣很多的軟體公司在進行專案或軟體設計時，
通常人員都是校長兼撞鐘，不過透過整個Overview掃下來，
希望對大家在進行軟體開發的時候，各個階段可以去思考相關的文件、分析、設計，UML可以帶來哪一些好處。

這邊很多diagram都只有舉一兩個當範例，因為篇幅的關係沒有全部貼上來請見諒。


http://www.dotblogs.com.tw/hatelove/archive/2009/10/24/11262.aspx