【UML】——爲何要使用UML

　　之前一提到UML，就想到了複雜的流程圖。很敬佩哪些想一想就能畫出整個系統的UML圖的人，由於他們頭腦中有整個軟件架構的藍圖，這樣在編寫實現的時候，就會知道哪一個地方改怎麼作，哪一個地方如何擴展。

　　而想成爲架構師，UML也是必備的技能。這裏就根據《大象——Thinking in UML》總結一些學習筆記。

　　平時老是在說什麼是面向對象，什麼是面向過程。

　　面向過程，就是典型的C語言這種，一個main函數，從頭走到腳，中間可能涉及到一些方法的調用，可是整個代碼徹底是流水線同樣。這樣就會致使一個問題，雖然代碼流程很清晰，可是不容易擴展，我須要修改某一個計算過程，有可能致使所有代碼須要重寫。

　　而面向對象，就是以一種對象的角度來編寫程序，設計程序，每一個對象具備本身的生命特徵。每一個對象內部具備一些複雜的變量以及方法，對外提供接口或者公共方法進行調用，這就是封裝。而對象之間能夠互相關的繼承，借鑑存在的方法，這就是繼承。相同類型的對象，能夠提取公共的部分，造成一個新的父類對象，這就是抽象。每一個相同類型的子對象之間可能存在不一樣的方法，這就是多態。

　　這樣，經過對象的方式，來看待世界，整個過程就變得解耦了，一旦須要擴展或者修改某個地方，單純的修改與之對應的對象就能夠了。

　　而這其中的難點，就是如何從現實世界中的業務場景轉換到抽象的對象模型；而經過複雜對象模型如何表示業務場景。

　　

　　經過上面這個步驟，就能夠從現實世界抽象出模型來表示業務場景了。

　　首先經過建模，把現實世界中須要的一些數據進行建模，創建對應的模型。

　　而後根據這些模型去設計相關的一些概念，好比控制類，實體類，以及邊界的展示類。

　　最後設計這些概念模型，進行代碼級的實現。

　　設計思想有了，那麼就出現了一種叫作RUP的統一建模的過程模式，經過這種建模的模式，能夠完整並且穩定的展現一個軟件的軟件生命週期。

　　經過這四個階段，9個核心，完美的詮釋了傳統軟件的生命活動，可是現代的軟件開發，大多講究極限編程，敏捷開發，想要經過快速的迭代更新，來進行快速的適應，以知足快速的需求變化。可是對於一些10年之久的系統來講，穩定纔是最重要的，所以這種統一過程每每是最佳的選擇。

　　對於UML來講，咱們最難的就是如何建模了！

　　首先要明確，建模的目的是什麼？須要知足什麼業務場景！其次，根據多種場景抽象出模型。

　　傳統的方式能夠經過自頂向下，或者自底向上的方式來進行。

　　自底向上，就是首先創建底層小對象的模型，再經過組合等方式，拼湊出完整的業務場景。

　　自頂向下，就是先進行大致的場景描述，再慢慢的細分功能。

　　通常都是這兩種方式，不斷的迭代，最終找到合適的方案。