最近在看《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圖形時應該能夠想像到對應的代碼實現，否則就別畫了。

轉載于:https://www.cnblogs.com/junqilian/archive/2008/03/14/1105328.html

總結

以上是生活随笔為你收集整理的Robert C. Martin关于UML、CASE的观点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。