初學UML的人可能只是把UML當作是單純的繪圖表示法 ,
以為UML就是放上Use Case Diagram , Class Diagram , Sequence Diagram就是UML了 ,....
錯 , ....UML會跟你的方法論有關 , 會跟你的開發程序有關 ,
但是常常還是有人會誤以為UML只是繪圖表示法 ,
所以當你要求外包商 , 要針對他們正在開發的系統去繪製UML產出時 , 常常看到的是 上帝的歸上帝 ,
嗯 , 說錯 , 是UML文件歸UML文件 , 系統程式歸系統程式 , 兩者完全沒有關聯性 , 純粹只是為了文件而文件 , 這樣的狀況是最糟糕的 , 但是偏偏這種方式卻常常有不少人能夠接受 , 讓我完全無法理解 ,
基本概念一: UML就是系統的藍圖 , 系統的開發應該是根據規劃的藍圖去實做
這麼說好了 , UML , 你可以把它想像是房子的藍圖 , 房子的所有規劃 , 包含電線管路要怎麼拉 , 怎麼走 , 污水管理怎麼走 , 電梯要裝幾個 , 逃生梯開在房子的左邊或是房子的右邊 , 戶與戶之間的大門是向內開還是向外開(之前 , 有大陸的新聞說 , 有棟房子 , 住戶與住戶的大門是向外開的 , 所以 住戶A開了大門就會堵住住戶B的大門 ...) ,
那你可以想像說 , 明明是電梯大廈的藍圖 , 結果蓋出 18樓沒有電梯的房子嗎? ,
如果你能接受房子的實體應該是根據房子的藍圖蓋出來的 ,
那你怎會能接受 做出來的系統程式完全不根據藍圖(UML)去開發???
基本概念二: UML 的每個Diagram 是有關聯性 , 有可追蹤性的
舉例來說 , Use Case Diagram 談的是User Requirement的蒐集 ,
也就是說你在圖上畫的每個Use Case , 它都應該會被實現(Use Case Realization) , 而每個Use Case Realization 都會被轉化為 SA , (產生 Boundary , Control , Entity) , 再由此衍生出相關的SD , 而產生出 對應的Class , Class Diagram , Sequence Diagram , 等等 ,
這其中就衍生出可追蹤性(traceability) , 照道理來說 , 你可以正向由來源去追蹤每個項目的下一個產生是甚麼 ,
就舉 Use Case 來說 , 如果你的系統有畫了 10 個 Use Case , 那麼你可以看一下每個Use Case 是否有被實做 , 這個Use Case 實做的衍生物是哪些 , 一路追下去 , 保證你絕對不會短缺有任何該做的功能被遺漏沒有實現....(反向也是如此 , 你隨便挑出一個Class , 它一定是某個或某幾個use case實做必須的衍生物 , 絕對不會有那種無中生有的Class , 除非那是垃圾Class或是雞肋Class )
但是 , 一般人員很少有這樣的認知 , 多半是為了交文件而文件...
基本概念三: 是不是一定要畫UML才能開始作系統
這點我的答案是看狀況而定 , 如果你的系統很小 , 然後你也都明確的了解使用者的需求 , 然後要開發的功能與平台都十分明確 , 你也已經評估過程式碼不多 , 甚至你都不打算拆出系統階層 ,或是類別 ,
那根本就不需要UML的介入 ,
還有你是那種做到哪裡才想到哪裡的 , 也不需要 , 因為當你不作規劃 , 那UML對你也沒有幫助...
因為UML的開端就是 Use Case Diagram , 藉由 Use Case 去蒐集與釐清使用者的需求 , 系統的邊界 ,
有哪些系統外部的人或系統(這個就是Actor)會與我們的系統有互動 , 而那些Use Case 就是我們的系統會對外提供的服務(功能) , 也是我們的系統實做的清單 ,....
我看過廠商畫了 某些Actor , 我問廠商說 , XXX Actor , 它會跟我們的系統有互動嗎? , 如果 XXX Actor 是人 , 那他會登入我們的系統嗎? , 如果 XXX Actor 是另一個系統 , 那麼它跟我們的系統之間是如何溝通互動的....
廠商答不出來 , 因為他根本只是隨便亂畫 , 為了交文件而文件 ,
審閱這些為了交文件而文件 , 連寫文件的人自己都說不出個道理的文件 , 實在是浪費人生...
基本概念四：UML是否一定要畫的巨細靡遺?
我的答案是看你的開發模式是哪一種 , 或者說你是奉行或是採行哪一種方法論 ,
像如果你是採行MDA的開發模式 , 則UML Model 一定要畫的清清楚楚 ,
因為你的Model 就是要產生的系統程式碼的原始規格 ,
不過 MDA 一般也都會搭配類似程式碼產生器的工具 ,
舉例來說 , 像是 Eclipse 之下的 EMF , GEF , GMF 就是你先規劃好不同物件之間的關係 , 關聯 , 限制等等 . 就可透過工具轉換模型變成可執行的程式碼 , 所以有些類型繪圖工具 , 你只要詳細的設定好 Model , 幾乎就可以透過工具完成80%以上的工作 , 讓要寫的程式減少 ,
但是也有人堅持 , UML 只是單純的繪圖表示法 , 只要挑重點畫就可以 ,
這樣也不是不行 , 前提是: 你必須要了解你的系統的全貌 , 每個類別間的關係.. , ...之類的
另外要交接時 , 也可能會因為你畫的十分簡略 , 所以你會有很多東西不在UML圖形中 ,
如果你接手前人這樣的遺產時 , 當你要接手維護時 , 你想要知道某某Class有沒有XX功能 , 或是你想要換掉它 , 但是你又無法從前人留給你的UML中 , 看出端倪時 , 那你只好自求多福 , 或是拜託前人還在公司沒有離職可以讓你問....
或者是當幾年前你開發的系統 , 後續的系統維護者有問題需要詢問你的時候 , 最好是你的記憶好到可以記得 n 年你實做的系統明細....
突然發現又在離題 ...
以為UML就是放上Use Case Diagram , Class Diagram , Sequence Diagram就是UML了 ,....
錯 , ....UML會跟你的方法論有關 , 會跟你的開發程序有關 ,
但是常常還是有人會誤以為UML只是繪圖表示法 ,
所以當你要求外包商 , 要針對他們正在開發的系統去繪製UML產出時 , 常常看到的是 上帝的歸上帝 ,
嗯 , 說錯 , 是UML文件歸UML文件 , 系統程式歸系統程式 , 兩者完全沒有關聯性 , 純粹只是為了文件而文件 , 這樣的狀況是最糟糕的 , 但是偏偏這種方式卻常常有不少人能夠接受 , 讓我完全無法理解 ,
基本概念一: UML就是系統的藍圖 , 系統的開發應該是根據規劃的藍圖去實做
這麼說好了 , UML , 你可以把它想像是房子的藍圖 , 房子的所有規劃 , 包含電線管路要怎麼拉 , 怎麼走 , 污水管理怎麼走 , 電梯要裝幾個 , 逃生梯開在房子的左邊或是房子的右邊 , 戶與戶之間的大門是向內開還是向外開(之前 , 有大陸的新聞說 , 有棟房子 , 住戶與住戶的大門是向外開的 , 所以 住戶A開了大門就會堵住住戶B的大門 ...) ,
那你可以想像說 , 明明是電梯大廈的藍圖 , 結果蓋出 18樓沒有電梯的房子嗎? ,
如果你能接受房子的實體應該是根據房子的藍圖蓋出來的 ,
那你怎會能接受 做出來的系統程式完全不根據藍圖(UML)去開發???
基本概念二: UML 的每個Diagram 是有關聯性 , 有可追蹤性的
舉例來說 , Use Case Diagram 談的是User Requirement的蒐集 ,
也就是說你在圖上畫的每個Use Case , 它都應該會被實現(Use Case Realization) , 而每個Use Case Realization 都會被轉化為 SA , (產生 Boundary , Control , Entity) , 再由此衍生出相關的SD , 而產生出 對應的Class , Class Diagram , Sequence Diagram , 等等 ,
這其中就衍生出可追蹤性(traceability) , 照道理來說 , 你可以正向由來源去追蹤每個項目的下一個產生是甚麼 ,
就舉 Use Case 來說 , 如果你的系統有畫了 10 個 Use Case , 那麼你可以看一下每個Use Case 是否有被實做 , 這個Use Case 實做的衍生物是哪些 , 一路追下去 , 保證你絕對不會短缺有任何該做的功能被遺漏沒有實現....(反向也是如此 , 你隨便挑出一個Class , 它一定是某個或某幾個use case實做必須的衍生物 , 絕對不會有那種無中生有的Class , 除非那是垃圾Class或是雞肋Class )
但是 , 一般人員很少有這樣的認知 , 多半是為了交文件而文件...
基本概念三: 是不是一定要畫UML才能開始作系統
這點我的答案是看狀況而定 , 如果你的系統很小 , 然後你也都明確的了解使用者的需求 , 然後要開發的功能與平台都十分明確 , 你也已經評估過程式碼不多 , 甚至你都不打算拆出系統階層 ,或是類別 ,
那根本就不需要UML的介入 ,
還有你是那種做到哪裡才想到哪裡的 , 也不需要 , 因為當你不作規劃 , 那UML對你也沒有幫助...
因為UML的開端就是 Use Case Diagram , 藉由 Use Case 去蒐集與釐清使用者的需求 , 系統的邊界 ,
有哪些系統外部的人或系統(這個就是Actor)會與我們的系統有互動 , 而那些Use Case 就是我們的系統會對外提供的服務(功能) , 也是我們的系統實做的清單 ,....
我看過廠商畫了 某些Actor , 我問廠商說 , XXX Actor , 它會跟我們的系統有互動嗎? , 如果 XXX Actor 是人 , 那他會登入我們的系統嗎? , 如果 XXX Actor 是另一個系統 , 那麼它跟我們的系統之間是如何溝通互動的....
廠商答不出來 , 因為他根本只是隨便亂畫 , 為了交文件而文件 ,
審閱這些為了交文件而文件 , 連寫文件的人自己都說不出個道理的文件 , 實在是浪費人生...
基本概念四：UML是否一定要畫的巨細靡遺?
我的答案是看你的開發模式是哪一種 , 或者說你是奉行或是採行哪一種方法論 ,
像如果你是採行MDA的開發模式 , 則UML Model 一定要畫的清清楚楚 ,
因為你的Model 就是要產生的系統程式碼的原始規格 ,
不過 MDA 一般也都會搭配類似程式碼產生器的工具 ,
舉例來說 , 像是 Eclipse 之下的 EMF , GEF , GMF 就是你先規劃好不同物件之間的關係 , 關聯 , 限制等等 . 就可透過工具轉換模型變成可執行的程式碼 , 所以有些類型繪圖工具 , 你只要詳細的設定好 Model , 幾乎就可以透過工具完成80%以上的工作 , 讓要寫的程式減少 ,
但是也有人堅持 , UML 只是單純的繪圖表示法 , 只要挑重點畫就可以 ,
這樣也不是不行 , 前提是: 你必須要了解你的系統的全貌 , 每個類別間的關係.. , ...之類的
另外要交接時 , 也可能會因為你畫的十分簡略 , 所以你會有很多東西不在UML圖形中 ,
如果你接手前人這樣的遺產時 , 當你要接手維護時 , 你想要知道某某Class有沒有XX功能 , 或是你想要換掉它 , 但是你又無法從前人留給你的UML中 , 看出端倪時 , 那你只好自求多福 , 或是拜託前人還在公司沒有離職可以讓你問....
或者是當幾年前你開發的系統 , 後續的系統維護者有問題需要詢問你的時候 , 最好是你的記憶好到可以記得 n 年你實做的系統明細....
突然發現又在離題 ...
