敏捷式軟體開發 (Agile Software Development)：原則、模式與實踐——第14章 使用UML

標籤：

第14章　使用UML

　　在探索UML的細節之前，我們應該先講講何時以及為何使用它。UML的誤用和濫用已經對軟體項目造成了太多的危害。

 

14.1 為什麼建模

　　建模就是為了弄清楚某些東西是否可行。當模型比要構建的真實實體便宜很多時，我們就會使用模型來研究設計。

14.1.1 為什麼構建軟體模型

　　當我們有一些確定的東西需要測試，並且使用UML要比使用代碼測試的代價更低一些是，就使用UML。比如，我有一個關於某個設計的想法。我想知道團隊中的其他開發人員是否認為它是一個好的想法，於是，我就在白板上畫一幅UML圖，並詢問團隊成員的意見。

14.1.2 編碼前應該構建面面俱到的設計嗎

　　其實，我們根本無法清楚地知道在編寫代碼前先建立面面俱到的UML設計到底是不是一件划算的選擇。

14.2 有效使用UML

　　我們不能像其他工程學科使用藍圖和模型那樣輕率地使用UML。那麼，我們應該什麼情況下使用UML呢？

　　在和他人交流及協助解決設計問題方面，圖示是最為有用的。重要的一點是，圖示的詳細程度應該只是達成目標所必須的。你可以繪製具有大量裝飾的圖示，但那是損害生產力的做法。請確保圖示簡單、乾淨。UML圖不是原始碼，不應該當做聲明所有方法、變數和關係的地方。

14.2.1 與他人交流

　　使用UML在軟體開發人員間交流設計構想是非常方便的。在交流演算法細節方面，UML並不是非常適合。

14.2.2 脈絡圖

　　在建立大型系統的結構脈絡圖（road map）方面，UML也很有用。這種脈絡圖可以使開發人員快速找到類之間的依賴關係，並提供了一份關於整個系統的參考。

14.2.3 項目結束文檔

　　編寫需要儲存的設計文檔的最好時機是在項目結束時，並把它作為團隊的最後一項工作。這種文檔會精確地反映出設計的狀態，對後續的團隊來說非常有用。UML圖必須經過仔細考慮，我們不需要數千頁的順序圖。我們想要的是那些描述系統關鍵點的少量重要的圖示。

14.2.4 要保留的和要丟棄的

　　請養成丟棄UML圖的習慣。大部分UML圖都不應該長久存在。僅僅需要保留那些具有高的長期存在價值的圖示。
　　有些圖保持起來是有用的：那些表達了系統中公用設計方案的圖示。請把那些記錄了難以從代碼中識別出來的複雜協議的圖示儲存起來。這些圖示提供了系統中不常提及部分的脈絡圖。它們以一種比代碼更好的表達方式記錄了設計者的意圖。

14.3 迭代式改進

14.3.1 行為優先
　　我喜歡從行為開始。如果我認為UML會有助於我思考一個問題，我會首先繪製一幅有關問題的簡單順序圖或者共同作業圖表。以手機完成撥打電話為例。

　　我們可以想象軟體檢測每一次按鍵，並向控制撥號的某個對象發送訊息。因此我們繪製出一個Button對象和一個Dialer對象，以及Button向Dialer發送的多條digit訊息。

　　當Dialer收到一條訊息時把這個數字顯示在螢幕上。

　　Dialer最好能讓擴音器發出聲音。因此我們讓它向Speaker對象發送tone訊息。

　　在某個時候，使用者會按下Send按鈕，表示號碼已撥完。此時，我們得讓手機無線通訊裝置區串連行動電話通訊並把所撥的電話號碼傳遞出去。

　　一旦串連建立起來，Rado就可以讓Screen點亮“正在使用”指示燈。這條訊息無疑得從一個不同的控制線程中發出，這一點是通過訊息序號前面的字母來表示的。最終的共同作業圖表如下：

14.3.2 檢查結構

　　為了研究這幅共同作業圖表對於代碼結構來說意味著什麼，因此我們建立了一幅類圖：

　　為了隔離Button和Dialer：

Dialer不需要一個名為buttonPressed的方法，為了隔離Dialer和ButtonListener，使用了適配器：

14.3.3 想象代碼

　　如果畫圖不能想象出它所表示的代碼，那麼就是在構建空中樓閣。停止繪圖，想一想該如何把它翻譯成代碼。決不為了畫圖而畫圖。

14.3.4 圖的演化
　　我們很可能是在一塊白板前做這些，並且可能不會記錄下所做的工作。我們不想非常規範或者非常精確。使用白板的目的不是為了讓訊息序號中的每一個點都正確，而是為了讓站在白板前的每個人都能理解討論的內容，是為了趕快停止討論，開始編碼。

14.4 何時以及如何繪製圖示

　　不要指定“必須圖示一切”這樣的規則。大量的時間和精力會浪費在繪製沒人會看的圖示上面。

　　可以繪圖的情況如下：

• 幾個人都需要理解設計的某個特定部分的結構，因為他們都將同時工作於其上。當每個人都認為已經理解時，就停止。
• 你希望團隊能夠達成一致，但是有兩個或者更多人不同意某個特定元素的設計。把討論限定在一個時間盒內，然後選擇一種策略的手段，比如：投票或者公平裁判。在時間盒終止或者能夠做出決策時就結束。然後擦掉圖示。
• 你想嘗試一個設計想法，並且圖示能夠有助於你進行思考。當你可以使用程式碼完成思考時就停止。丟棄掉圖示。
• 你想向其他人或者自己解釋代碼某些部分的結構。當通過瀏覽代碼可以更好地進行解釋是就停止。
• 快要到達項目的尾聲，並且客戶要求把圖示作為向他人提供的一組文檔中的一部分。

　　不要畫圖的情況如下：

• 過程要求。
• 不畫圖會有負罪感或著認為這是好的設計者要做的事情。編寫代碼才是好的設計者要做的事情。他們僅在必要時才畫圖。
• 為了在編碼前建立出面面俱到的設計階段文檔。這種文檔基本上沒有任何價值，卻浪費了大量時間。
• 為了讓其他人編碼。真正的軟體架構師要參與到自己設計的編碼中。

14.5 結論

　　UML是一個工具，不是最終結果。作為一個工具，它可以協助你思考和交流設計。如果少量使用，它會給你帶來巨大好處。如果過度地使用，它會浪費你大量時間。當使用UML時，少即是好。

 

 

 

摘自：《敏捷式軟體開發 (Agile Software Development)：原則、模式與實踐(C#版)》Robert C.Martin    Micah Martin 著

轉載請註明出處：

JesseLZJ
出處：http://jesselzj.cnblogs.com

敏捷式軟體開發 (Agile Software Development)：原則、模式與實踐——第14章　使用UML