TOC
如何使用UML
1. 為什麼要建模
-
建模型就是為了弄清楚某些東西是否可行
-
當模型比要建構的真實實體便宜許多時，我們就會使用模型來研究設計
為什麼建構軟體的模型
- 當我們有一些確定的東西需要被測試，並且使用UML比使用程式碼來測試的代價更低時，我們就該使用UML
- 寫程式之前應該建構面面俱到的設計嗎?
2. 有效使用UML
- 在和他人交流以及幫忙解決設計問題方面，圖示是最有效用的
- UML圖不是原始程式碼，不應該當作宣告所有方法、變數和關係的地方
- 交流設計構想方面是非常方便的，但是不適合用來交流演算法的細節
- 在建立大型系統的結構脈絡圖(Road Maps)方面UML也很管用，這種脈絡圖可使開發者快速找到類別之間的依賴關係
專案結束文件
- 編寫需要保存的設計文件的最佳時機，是在專案結束的時候，可把它作為團隊的最後一項工作
- 僅需要描述系統關鍵重點的少量重要圖示
哪些是要保留的和要丟棄的
- 請養成丟棄UML圖的習慣，大部分的UML圖都不應長久存在
- 請把那些紀錄了"難以從程式碼中識別出來的複雜協議"的圖示給保存起來
- 僅僅保留那些具有長期存在價值的圖示
3. Iterative 改進
- 人類能夠做得好的都是"採取小步前進然後就對結果進行評估"的那些方法所做的事情
- 人類做不好的都是"採取大步跳躍"的那些方法做做的事情
行為優先
- 可以從先繪製一幅有關問題的簡單循序圖或協作圖來開始製作UML
- 因為我們無法提前得知將會出現這些物件，故我們只是知道我們得讓某些事情發生，於是就建立物件來完成這些事情
- 透過逐步建立物件的方式來實現
檢查結構
- 透過建立類別圖的方式來補充協作圖
- 用於檢查協作圖中的每個物件所屬的類別以及每個鏈的關聯
- 最重要的事情是分析依賴關係
想像程式碼
- 將圖示作為程式碼的速記，而不是替代品
- 不要只是想著一直畫下去，要先想一想該如何將這些圖示翻譯成程式碼
圖的演化
- 以迭代的方式進行共同演化
- 從一點點的動態關係作為開始 > 探索這些動態中所蘊含的靜態關係 > 根據一些好的設計原則來更改靜態關係 > 回頭修改動態圖 －圖示只是為了讓站在白板前的每個人都能理解討論的內容，我們是為了能夠趕快停止討論趕快開始寫程式的目的來繪製圖示的
4. 何時以及如何繪製圖示
何時要畫圖? 何時不要畫圖?
可以畫圖
- 當有幾個人都需要理解設計中某個特定部分的結構時，因為他們都將同時工作在這種上面，所以當每個人都認為已經了解時就該停止
- 希望團隊能夠達成一致的共識時，把討論限定在一個時間盒內，然後選擇一種決策的手段:例如投票或公平裁判。在時間盒中止或能夠做出決策時就結束。
- 想要嘗試一個設計想法時，因為圖示有助於你進行思考。當可以利用程式碼思考時就該結束。
- 要向其他人或自己解釋程式碼某部分的結構時，當透過瀏覽程式碼能解釋得更棒時就該停止。
- 快抵達專案的尾聲了，而客戶要求把圖示作為向他人提供的一組文件中的一部分時
不要畫圖
- 程序流程上的要求
- 罪惡感導致需要畫圖才是好的設計
- 為了在寫程式之前建立出面面俱到的設計階段文件 (通常這類文件基本上沒有任何價值，卻耗費了大量的時間)
- 為了讓其他人來寫這個設計的程式碼
CASE工具
- 給團隊裝備一套昂貴的CASE工具也許會有好處，但是在購買這些很可能會成為閑置不用的東西之前，請先透過自己的實驗證實那些好處
文件
- 應該簡明扼要的描述
- 軟體文件的價值和數量成反比
- 通常需要大量的工作才能把文件變小，不過這些工作是值得的，因為人們會去閱讀小的文件，而不願意去閱讀100頁的大部頭
5. 總結
- 站在白板前的幾個人可以利用UML來幫助他們思考設計問題
- 最好能夠先探索動態情，境然後再確定他所隱含的靜態結構
- UML CASE 工具在某些情況下是有用的，但是對於一般的開發團隊來說，這些工具更有可能成為障礙，而不是有所幫助
- UML是一個工具而不是最終結果
- 作為一個工具它可以幫助你思考和交流設計，如果過度使用他會浪費你大量的時間
- 當使用UML時，少即是好