Robert C. Martin關於UML、CASE的觀點

最近在看《Agile Principles,Patterns,and Practices in C#》, written by Robert C. Martin and his son Micah Martin. 其中寫到他們關於UML、CASE使用的觀點，有點顛覆傳統的意味，覺得很好玩兒，貼出來和大家共用。我的理解也許還有偏差，不能完全代表Robert的觀點，純屬標題黨吸引眼球，呵呵。

1、要對完全掌握UML的n多種圖形嗎？

UML有類圖啊、狀態圖啊什麼的好多種，但對程式員來講，一般用到的也無非就那麼幾種：類圖（Class Diagrams）、對象圖（Objects Diagrams）、順序圖（Sequence Diagrams）、共同作業圖表（Collaboration Diagrams）和狀態圖（State Diagrams）；

2、為什麼要建模？

有人可能說：架構設計師不用UML畫上一大堆的圖形那還叫架構師嗎？可Robert說，非也，架構師是用代碼而不是一大堆亂七八糟的UML圖形，UML圖形只是用來交流的工具，是用來畫在白板或者白紙上，用完就扔的，而不是把它弄成一段貌似正式的文檔裝訂成冊裝點門面。

3、開發過程一定要建模嗎？

非也，建模的目的是為了測試某個方案是否可行，既然是測試，當然那個成本低就用哪個，如果直接用代碼和畫複雜的UML圖代價差不多的話，還不如直接用代碼。

4、什麼時候要畫UML圖，什麼時候不用畫？

需要畫的情形：

• 幾個人需要同事做某件事，從而他們都要瞭解整個結構，需要畫UML圖統一思想。大家達成共識了，這些圖形也就功德圓滿，可以擦掉扔掉了。
• 你想讓團隊達成共識，但有那麼一兩個不同意你的方案。你需要在固定的時間段內來討論一下，討論時間用完了就應該把結果定下來，不要總沒完沒了的討論、扯來扯去的。可以通過投票或者權威人士判定。
• 當你在思考一個設計時，可以用UML來輔助思考，想清楚了就可以把這些圖形扔掉了。
• 你要把你的代碼解釋給別人聽時，需要畫一些。
• 項目要結束了，客戶非要你提交UML圖當做文檔時，得畫吧。

下面的情形就不用畫了：

• 貌似軟體開發過程要求了要畫UML然後在coding？
• 你覺得要不畫點UML圖什麼就會覺得內疚，其實大可不必。
• 建立複雜的UML比寫代碼還麻煩呢，這種情況還不如不畫

5、關於CASE工具

在你打算投資購買一套CASE工具之前，要仔細想想清楚哦～

• CASE工具不是能讓我們在畫UML圖時更容易嗎？不，他只能是增加複雜度。因為你學習這個軟體也得費半天勁。
• CASE工具不是能讓一個大的團結在畫UML圖時能更方便的合作嗎？只是有時候是，但是一般一個很大的團隊根本用不著畫那麼多那麼複雜的UML圖形。
• CASE工具不是能自動生產代碼嗎？的確是，但是維護修改這些生產的代碼估計和你自己寫也省不了多少事，所以建議在花錢買CASE工具之前好好衡量一下到底能給你提高多少的生產力。
• 那把CASE工具和IDE整合在一起的怎麼樣？嗯，這個想法不錯。但是坦率的說，我寧願把投入到CASE的這部分錢花在IDE在編程方面的改進上。

6、有的時候使用文字格式設定的比圖形更簡單。還有機會使用自動化工具做進一步處理。比如針對State Transitions Tables的SMC（Statce Machine Compiler） 可以參考 http://www.objectmentor.com

 

嗯，結論：

不要為了UML而去UML；UML只是交流工具，交流清楚了就可以扔掉了；在畫UML圖形時應該能夠想像到對應的代碼實現，否則就別畫了。