這學期開始認真學習設計模式這門課，老師課上說了一句話：在設計模式出現以前，軟件開發是門藝術，只有那些有天賦的程序員才能寫有優雅的代碼；設計模式被人們總結出來之后，軟件開發就成了一門技術了，有著固定的模式可以參考，沒有天賦的程序員也可以寫出很好的代碼。
先不管這句話的正確與否，但是有一點是確定的，軟件的開發過程中，設計是非常重要的。有一個好的設計能夠將軟件開發失敗的機率降到最低。
設計模式不應該被視為軟件開發的說明書，照著那一條一條的模式套用并不一定能寫出來好的程序，正確的態度應該是把它們作為軟件設計的經驗和建議來看。
最近看了下那本《敏捷軟件開發：原則、模式與實踐》，感覺確實是本好書，可以看出來作者對軟件開發的功力非常豐富。我發現作者在說明軟件開發過程的時候大量使用了UML，以前我都認識這些東西很虛，很麻煩。現在看這本書的時候卻有點了不同的體會，哈哈，看來是我以前層次太低了。UML實在是一個好東西，清晰明了，用來描述復雜的系統的時候真有種撥云見日的感覺。
下面簡單寫一下UML的基本知識：
1.識別參與者
2.抽取用例
用例中有兩點需要說明一下：擴展(extension)/包含(include)
擴展：它們之間互不引用，僅僅插入到被擴展用例中
包含：包含用例會引用被包含的用例
基本用例完成之后，可以根據參與者將其分類組織起來，形成系統的邊界圖來匯總顯示。
3.領域模式(domain)
這是一種類似于UML類圖,但是它們之間有很大的差別，它并不會對應于編碼中的類(class)。
4.類之間的關系
關聯：以一條線連接兩個類表示，表示它們之間相互包含。更常見的是一種帶箭頭單向關聯關系。
聚合：以一個白色菱形箭頭表示類之間的“整體/局部”關系，同樣聚合關系的一個變體“組合”，以一個黑色菱形箭頭表示，這也是一種“整體/局部”關系，但是“部分”不能脫離“整體”而存在，“整體”也必須負責管理“部分”的生存期。
舉例：家庭和人是聚合關系，而電腦與CPU是組合關系