《UML for Java Programmers》記

 1 當你做圖的時候能夠想象到你的代碼是極其重要的。我們把圖當作瞭解代碼的一條捷徑，並不是替代代碼。如果你畫著圖但是不能想像出它代表著什麼樣的代碼，你是正在空氣中建築著城堡。停下來你正在做的，想想如何如能將它可以轉化成代碼。不要為了圖而畫圖，你必須時時刻刻記得，代碼才是你要表現的。

--- 設計師從Coder進化來的，Coder的經驗（代碼-->重複的代碼習慣-->模式） --> 設計師

     設計師在設計的時候，正好是上面過程的反方向。領域具體問題 --> 抽象的模式 -- >曾經類似的經驗 -->曾經寫過的代碼（實現）。

2 使用白板的目的不是為了正確地標出圖上序號的點，而是使每個圍在白板前討論的人都理解它，最終目標是停止在白板上畫而開始編寫代碼。

--- 項目的目的是為了結束項目。

    UML（溝通方式--設計與開發人員）的目的是實現，設計的實現，溝通理解是過程。

 

3 什麼時候開始畫圖？

   多人開發時，需要每個人都理解特定部分，開始畫圖；每個人都理解了，停止畫圖。

   對某處設計存在不同意見是畫圖，討論作出決定時停止畫圖，擦掉這些圖。

   當你需要探討一個設計的想法時，畫圖能夠幫你更好的地思考。當你得到了能夠協助你完成思考的代碼的要點的時候，扔掉這些圖。

   當你需要向其他人或自己解釋一部分代碼的結構的時候，你可以畫圖。當你覺得其實最好看代碼來進行解釋的時候，停止畫圖。

   當醒目快結束，顧客需要時開始畫圖。

  什麼時候停止畫圖？

   不是因為過程需要。

   不是為了做一個好的設計師而畫圖，彷彿說不畫圖就不是好的設計師。

   不是為了別人實現代碼才畫圖，為了協助自己的實現才畫圖。

---為了真正的需要才畫圖（需要就是畫圖的目標--實現）

4 依賴關係 java實現

 

  

 

  

5 代碼真是能夠用於描述系統的一部分嗎？實際上，這應當是每個設計者和開發人員的目標。團隊應該努力去建立表述清楚和可讀性強的代碼，使更多的代碼能夠描述自己，更少地需要圖，最好整個項目不需要圖。

 

6 有關用例要留意的一件事情是：明天它們將要發生變化。

   如果有些事情明天將要發生變化，你今天就不需要真正去捕獲細節。實際上，你要盡量延遲細節的捕獲，直到最後可能的時刻。

 

7 Martin文檔第一要律：只編寫那些你真正需要的有意義的文檔。