前一段出差耽誤了，後來CSDN的Blog就一直上不來，現在終於可用了，趕緊補上。
總則
本次講座雖然冠名以“UML實作細節”，我卻覺得叫做“UML與用例驅動開發”更爲合適。當然，我能體會到think的良苦用心——體現講座的實踐價值，凸現“聚焦最後一公里”的理念，不過這個名字還是容易使人誤解，以爲就是平常教UML的講座。實際上，講座涵蓋了軟件開發前期（分析和設計）的幾個基本過程，並且通過實際案例，帶領我們實踐了整個過程。對我來說，最大的收穫就在於實踐過程中的諸多細節，或者糾正了誤解，澄清了迷惑，或者印證了自己原本不太清晰的一些想法。下面的複習筆記就是對此的記錄。
首先，應該看到當代軟件開發方法論雖然百花齊放，諸如UP，XP，FDD等各自擁有大批擁護者，然而其中都體現了同樣的核心思想：
1.迭代開發過程——這是最基本的要素，Ivar Jacobson在中國之行中曾經提到，即使最基本的，最簡單的實際軟件項目（他認爲10人即是大的開發團隊），也應該採用迭代開發——讓瀑布式開發見鬼去吧！
2.基於架構——在當代軟件，特別是商用軟件中，怎麼強調架構的重要也不過分
3.用例驅動——各種方法可能術語不同，比如UP中叫Use Case，XP中叫User Story，其中定義的表現形式不同，可實際表達的本質都是一致的——從用戶的視角去觀察軟件的價值；
4.面向對象——儘管各種方法都沒有限制必須採用面向對象的思想，但對於大多數項目而言，顯然OO是必選項，也擁有最多的最佳實踐案例。
這裏應當注意，不要把UML和這些方法相混淆，UML是一種語言，一種表現形式，它並沒有告訴我們應該做什麼和怎麼做，只是幫助我們想法記錄下來，以便與他人交流。在我看來，UML的最大好處就在於爲大家提供了一套既嚴謹又容易理解的標準符號，就像英語一樣，程序員的世界從此縮小了距離。在實際中，UML的九種圖不必一一用到，不要爲了用UML而用UML，而應該把UML視爲工具，需要用才用。最重要的是“用例圖”“類圖”和“序列圖”。
。 軟件開發的分析與設計過程可以分爲以下幾個步驟：
0.業務建模
1.獲取需求
2.需求分析-靜態結構
3.需求分析-動態行爲（特徵）
4.設計
這幾步是自外而內，逐步求精的過程，在我們實施改進的時候應當循序漸進，本着“能用一點用一點，用一點是一點－－匍匐前進”的原則進行；這個觀點很重要，可以說是實踐UML的重要指導思想。以前我自己也有類似的想法，不過沒有think總結的透徹，也沒有他那麼自信:P