前幾天在training公司新人的時候，剛好負責了這個部分。
分享給比較沒經驗的PGR參考一下。
這邊列出來的有五張圖，分別是
1.Use Case Diagram
2.Activity Diagram
3.State Machine Diagram
4.Class Diagram
5.Sequence Diagram
這五張圖是我覺得PGR要看懂，才會降低各層級溝通的門檻。

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
這張圖就更細了，最適合PGR看的一張圖，因為就跟trace程式一樣，
可以知道哪一些物件什麼時候要被初始化，物件與物件之間如何互動，
該傳遞與回傳什麼樣的訊息，
搭配state machine diagram去進行condition的判斷，
搭配class diagram去完成物件與物件之間的互動。
這張圖其實很適合擺在程式規格裡面，用來描述PGR在進行這支功能設計時，
該有的logic flow....