UML圖分析

你真的知道UML是作什麼用的嗎？

      優秀的UML有什麼特徵？

      何時該用UML？或者說，何時不應用UML？

      學了一學期的軟件工程，本身搗鼓了一個小系統，對UML這個東西有了一點感悟。我的以爲，UML是一個「貌似」能描述系統構架的東東，有不少人熱衷於畫這個東東，甚至熱衷於畫異常複雜的UML圖，並以此爲炫耀的資本。我一度很納悶，好像畫了這個東西，面子上就能過得去，就表示你的這個系統是符合軟件工程規範的。真的是這樣嗎？

      區區一個圖而已，能成爲衡量軟件質量的標準嗎？

      我很懷疑。但在用UML圖這件事上，個人經驗太少，不知道什麼是對，什麼不對。

      個人感受是：

      一、圖是給人看的，圖不能太複雜，不然看圖還不如看代碼。

      二、並非全部的程序都要用UML圖表示，或者說並非全部的程序都適合用UML圖來表示的。

 

 

      在學校的圖書館瞎逛，偶然碰見了《UML FOR JAVA PROGRAMMERS》一書，我驚訝地發現了書中闡述了許多我困惑的問題。書中的許多警句訓誡更是讓我醍醐灌頂，摘錄以下，以之爲後事之師：

 

 

 

UML適合作什麼？不適合作什麼？

      一、UML很是方便於軟件開發者之間溝通設計思想。UML特別適用於就關鍵設計思想進行溝通。另外一方面，UML不是特別適合交流算法的細節。

      二、UML適用於建立大型軟件結構的路線圖，這種圖幫助開發者看清楚類與類之間的關係。

 

 

 

圖應該畫成什麼樣？

      圖尤爲適合於他人交流思想，有助於解決設計問題。細節不要多，只要能使你實現目標。

 

 

 

什麼時候繪圖？

      一、當若干人須要同時進行開發時，這些人都須要理解一個系統的某個部分的設計結構時，應該繪圖。當全部的人都達成一致的時候，中止畫圖。

      二、當兩我的或更多的人對一個特定的元素如何設計持不一樣意見，你須要你的團隊協商時，應該繪圖。將討論限定在一個範圍內，肯定決策的方法，好比投票制公正裁決制。時間一到或已得出結論，就中止繪圖。而後擦掉圖。
      三、當你須要探討一個設計思路時，何況畫圖可以幫你更好的地思考時，應該繪圖。一旦得出結論，結束思考，就中止繪圖，而後扔掉這些圖。

      四、要向別人或者本身解釋代碼中某些部分的結構時，應該繪圖。若是進一步的解釋須要藉助代碼，就中止繪圖。

      五、項目接近尾聲，客戶要求將圖歸入文檔以轉交給另外一方時，應該繪圖。

 

 

 

什麼時候不要繪圖？

      一、不要由於流程的規定而繪圖。

      二、不要由於這兩個緣由——不繪圖會讓本身內疚，或認爲優秀的設計者都繪圖——而繪圖。優秀的設計者寫代碼，只是在必要的時候才繪圖。

      三、在編碼前的設計階段，不要爲了建立詳盡的文檔而繪圖。這樣的文檔幾乎一文不值，還浪費了大量的時間。

      四、不要爲寫代碼的人繪圖。真正的軟件架構師應當參與編碼，以實現本身的設計。

 

 

 

關於文檔

      良好的文檔是任何一個項目的根本。沒有它，團隊將在代碼的汪洋大海中迷失方向。但另外一方面，過多不恰當的文檔反而拔苗助長：由於團隊不只要看全部這些雜亂的、容易誤導人的文檔，還要面對代碼的汪洋大海。

      文檔是必須寫的，可是要謹慎。不少狀況下，決定不編寫哪些文檔與決定編寫哪些文檔一樣重要。

      複雜的通訊協議須要用文檔描述。

      複雜的關係模式須要用文檔描述。

      複雜的可重用框架須要用文檔描述。

      可是，它們都不須要成百頁的UML。軟件文檔應該言簡意賅。軟件文檔的價值與它的大小成反比。

 

 

 

順序圖的應用場合

      一、須要當即向某人描述一組對象之間的協做方式時；

      二、想把這種協做關係形象化以便於本身思考時。

      順序圖只是偶爾爲之以鍛鍊分析能力的工具，而並非必不可少的文檔。

      偶爾在白板上繪製順序圖是頗有價值的。在一張小卡片上繪製五、6個順序圖，描述了子系統中最經常使用的交互場景，這樣的紙「價值千金」。相反，一個充斥了上千個順序圖的文檔，其價值還不如打印它們所用的紙。

      上個世紀90年代，軟件開發的最大謬論之一是，開發人員在編寫代碼以前應該爲全部的方法繪製順序圖。事實證實，這極大地浪費了時間。千萬不要這樣作。

 

     

 

      我認爲，一切的關鍵是，畫圖是爲了幫助咱們思考、交流和編程，不要爲了畫圖而畫圖。