第四，抉擇畫圖。畫UML圖是一種非常有用的活動，它也可能成為一種浪費時間的、可怕的活動。不需要制定什么都必須畫圖的規則，因為這樣的規則將比不用更糟糕。項目的大量時間和精力將會被浪費在追逐那個根本沒有人去讀的圖上。下面列舉了需要畫圖的情況：
當許多人一起需要同時進行開發時，這些人需要都理解一個系統的特定部分的設計結構時，開始畫圖。當所有的人都已經聲明理解了的時候，結束畫圖。
當兩個人或更多人不同意一個特定的元素如何設計的時候，需要團隊意見一致的時候，要找一個時間進行討論做出決定，比如投票，或一個公正的宣告的方式進行，這時需要畫圖。當決定做出來后，擦掉這些圖。
當需要探討一個設計的想法時，畫圖能夠幫我們更好地思考。當得到了能夠幫助我們完成思考的代碼的要點的時候，扔掉這些圖。
當需要向其他人或自己解釋一部分代碼的結構的時候，可以畫圖。當覺得其實最好看代碼來進行解釋的時候，停止畫圖。
當項目快要結束，顧客需要我們將圖與其他文檔一起提供的時候，開始畫圖。
在項目中使用UML，需要時刻記住的是保持簡單，并且結合軟件工程文檔，同時讓項目組對過程有統一的認識。很多成功的項目都采用用例驅動，迭代，遞增方法的。如果能把過程細化并且讓項目組掌握技巧，那么UML項目已經離成功不遠了。
系統開發過程
UML簡介
UML起源于面向對象的分析與設計方法。
在80年代末至90年代中，對面向對象分析與設計方法的研究發展到一個高潮。但是，諸多流派在思想和術語上有很多不同的提法，在術語、概念上的運用也各不相同，需要一種統一的符號來描述面向對象的分析和設計活動。UML應運而生。它不僅統一了Booch、Rumbaugh和Jacobson的表示方法，而且有進一步的發展，最終成為大眾所共同接受的標準建模語言。
UML是一種定義良好、易于表達、功能強大且普遍適用的建模語言。它融入了軟件工程領域的新思想、新方法和新技術。不僅支持面向對象的分析與設計，還支持從需求分析開始的軟件開發全過程。
