[修練營 UML]PGR應該要看懂的UML Diagram
前言
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?
- Use Case Diagram
可以幫助PGR瞭解自己正在寫的系統到底是什麼，
系統範圍有多大，
有多少相關外部界接系統，
有多少角色會使用這樣的系統，
系統要提供什麼樣的角色使用什麼樣的功能。
反思自己正要進行的規格功能設計，是屬於那一塊Use Case。 - Activity Diagram
通常是SA會先請User提供現行的作業流程文件，
再來進行企業流程分析，畫出Activity Diagram，有點類似flow chart，但是主要focus的目標在每一個activity。
PGR瞭解各個抽象等級的activity diagram，有助於知道自己正在進行的功能，
在Use Case Diagram裡面是屬於哪個Use Case，而該Use Case裡可能有很多Activity，可以幫助瞭解前後支程式的關聯與走向。
在開始動手寫程式之前，瞭解系統的前後關聯功能，傳遞參數等，
可以避免這支程式寫完單元測試可能通過，系統整合測試卻有一大堆問題(例如寫死測試值)。 - State Machine Diagram
這也是抽象層級可大可小的UML diagram，不過這張圖對PGR應該比較不陌生，
也是類似flow chart，但是focus的目標在於「狀態的改變」。
PGR如果瞭解這張圖，在看到規格上展開所有UI的prototype時，
才不會手忙腳亂，不知道什麼時候該做什麼事。
這張圖對設計UI動線很有幫助。
- 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)。
- Sequence Diagram
這張圖就更細了，最適合PGR看的一張圖，
因為就跟trace程式一樣，可以知道哪一些物件什麼時候要被初始化，
物件與物件之間如何互動，該傳遞與回傳什麼樣的訊息，
搭配state machine diagram去進行condition的判斷，
搭配class diagram去完成物件與物件之間的互動。
這張圖其實很適合擺在程式規格裡面，用來描述PGR在進行這支功能設計時， 該有的logic flow。
結論
如同「Coder to Developer」書上第一章所說的：
So there you are with your shiny new IDE and your coding skills and a vague idea of what it is that you want to produce. The temptation can be almost overwhelming to dive right in and start typing.
Don’t do it. Even the smallest of projects benefits from at least a little bit of planning up front, and yours is no different.
開始動手寫程式之前，請規劃好要怎麼寫這支程式，簡單的4W1H：
What are you writing?
When do you want to finish writing it?
Where do you expect it will be used?
Why are you writing this software?
How will you write the software?
希望各位都可以是優秀的Developer，而不是Coder。
blog 與課程更新內容，請前往新站位置：http://tdd.best/
