以前一提到UML，就想到了復雜的流程圖。很敬佩哪些想想就能畫出整個系統的UML圖的人，因為他們頭腦中有整個軟件架構的藍圖，這樣在編寫實現的時候，就會知道哪個地方改怎么做，哪個地方如何擴展。
而想成為架構師，UML也是必備的技能。這里就根據《大象——Thinking in UML》總結一些學習筆記。
平時總是在說什么是面向對象，什么是面向過程。
面向過程，就是典型的C語言這種，一個main函數，從頭走到腳，中間可能涉及到一些方法的調用，但是整個代碼完全是流水線一樣。這樣就會導致一個問題，雖然代碼流程很清晰，但是不容易擴展，我需要修改某一個計算過程，有可能導致全部代碼需要重寫。
而面向對象，就是以一種對象的角度來編寫程序，設計程序，每個對象具有自己的生命特征。每個對象內部具有一些復雜的變量以及方法，對外提供接口或者公共方法進行調用，這就是封裝。而對象之間可以互相關的繼承，借鑒存在的方法，這就是繼承。相同類型的對象，可以提取公共的部分，形成一個新的父類對象，這就是抽象。每個相同類型的子對象之間可能存在不同的方法，這就是多態。
這樣，通過對象的方式，來看待世界，整個過程就變得解耦了，一旦需要擴展或者修改某個地方，單純的修改與之對應的對象就可以了。
而這其中的難點，就是如何從現實世界中的業務場景轉換到抽象的對象模型；而通過復雜對象模型如何表示業務場景。
通過上面這個步驟，就可以從現實世界抽象出模型來表示業務場景了。
首先通過建模，把現實世界中需要的一些數據進行建模，建立對應的模型。
然后根據這些模型去設計相關的一些概念，比如控制類，實體類，以及邊界的展現類。
最后設計這些概念模型，進行代碼級的實現。
設計思想有了，那么就出現了一種叫做RUP的統一建模的過程模式，通過這種建模的模式，可以完整而且穩定的展示一個軟件的軟件生命周期。
通過這四個階段，9個核心，完美的詮釋了傳統軟件的生命活動，但是現代的軟件開發，大多講究極限編程，敏捷開發，想要通過快速的迭代更新，來進行快速的適應，以滿足快速的需求變化。但是對於一些10年之久的系統來說，穩定才是最重要的，因此這種統一過程往往是最佳的選擇。
對於UML來說，我們最難的就是如何建模了！
首先要明確，建模的目的是什么？需要滿足什么業務場景！其次，根據多種場景抽象出模型。
傳統的方式可以通過自頂向下，或者自底向上的方式來進行。
自底向上，就是首先建立底層小對象的模型，再通過組合等方式，拼湊出完整的業務場景。
自頂向下，就是先進行大體的場景描述，再慢慢的細分功能。
一般都是這兩種方式，不斷的迭代，最終找到合適的方案。