---

做系統分析的時候，我覺得特別有用。

你會很清晰的知道系統的需求=&>設計

這樣就能非常好的把握整體的工作。

另外就是用umlet這個工具，感覺非常 方便。

---

會畫，不過不是專業的那種。只是很隨意。

也就寫明：

• 實體類名，類注釋
• 繼承關係
• 表關聯關係，強關聯或者弱關聯
• 每個主要類，實現了怎樣的功能之類的。

最後留在項目目錄里。

沒人強制要求，也並不規範。目的是，一方面，自己將來看到的時候能回憶起來這個項目的相關內容；另一方面，也是為了將來別人接手我負責的這個項目的時候能有個簡單參照。

別人怎樣我不太清楚，至少我個人，在接手別人項目的時候對於表關係，繼承關係是一臉懵逼的。我希望有這樣一個圖示來給我說明這些。所以我盡量希望給別人提供這些。也許不一定有太大幫助。但是有幫助的時候，幫別人節省的時間絕對是遠遠超過我整理這個uml圖的時間的。嗯，划算的買賣，雖然受益人不是我。

我周圍畫UML的不多，一方面是這玩意需要學，忘了的時候還要去回憶那些箭頭，虛線之類的規範。另一方面，是需求變化太快，uml更新來不及。不過我倒是覺得，不需要那麼規範，能配合著代碼閱讀就好。而且還可以輔以文字。例如：不知道繼承是怎樣的箭線，那就隨便畫一條箭線，然後旁邊寫個extends，我相信這樣90%的開發人員都能看明白了。關於需求變更也同理，就算需求變更，至少表關係不會有太大的變化。有大的更新的時候再更新一下uml就好。

當然，uml只是個人習慣，可能只是個人執念而已。

---

有

出現在應付驗收的需求和設計文檔里。

---

代碼注釋都不寫畫個**圖（

---

不畫，現在連文檔里都很少見了。流程圖時序圖還是要畫的。

---

我寫代碼連注釋都懶得寫還讓我畫圖？

---

我猜如果有人回復他畫uml，那麼，要麼是他老闆要求，要麼是他工作量不飽和。9012年了，還有人提起這東西？

---

推薦閱讀：