最近在讀thinking in UML(大象，譚雲傑), 詳細闡述了分析，設計，建模和軟件統一過程的書，以後會陸續寫一些心得...
第一章:
- 對象是怎麼被抽象出來的？現實世界和對象世界看上去差別那麼大，爲什麼是這樣抽象而不是那樣抽象呢？（WHY）
- 對象世界由於其靈活性，可以任意組合，可是我們怎麼知道某個組合就正好滿足了現實世界的需求呢？什麼樣的組合是好的，什麼樣的組合是差點呢？（HOW）
- 拋開現實世界，對象世界是如此的難以理解。如果只是給我一個對象組合，我怎麼才能理解它表達了怎樣的含義呢？（WHAT）
因此我們需要：
- 一種把現實世界映射到對象世界的方法。
- 一種從對象世界描述現實世界的方法。
- 一種驗證對象世界行爲是否正確反映了現實世界的方法。
什麼是UML？
UML是一種建模用的語言(語言由基本詞彙和語法構成)。UML定義了一些建模所需要的，表達某種特定含義的基本元素；這些元素稱爲元模型，相當於語言中的基本詞彙，如用例，類等。另外，UML還定義了這些元模型互相之間關係的規則，以及如何用這些元素和規則繪製圖形以簡歷模型來映射現實世界；這些規則和圖形稱爲表示法或視圖(View)，相當於語言中的語法。
如同學習任何一種語言一樣，學習UML無非是掌握基本詞彙的含義，再掌握語法，通過語法將詞彙組合起來形成一篇有意義的文章。UML與其他自然語言和編程語言在原理上並無多大差別，無非是UML這種語言是用來寫說明文的，用自然世界和計算機邏輯都能夠理解的表達方式來說明現實世界。
然而，即使是同樣的語言，同樣的文字，同樣的語法，有的人能夠寫出優美的小說和瑰麗的詩句，有的人卻連一封書信都寫不通順。這種差別除了對語言掌握的功力之外，更重要的是寫作人自己腦子裏的思想和理念。好的文章除了語言功底，更重要的是言之有物，言之精確，言之全面，也就是作者要肚子裏有貨。如果以寫文章來對比的話，學習UML只是學會了一門語言，而要寫出一篇精美餓文章，卻要依靠寫作人對生活的感悟和昇華，這兩者缺一不可。因此比學會用UML建模本身更重要的是要理解UML語言背後所隱含的最佳實踐。
一，從現實世界到業務模型：
建立模型是人們解決現實世界問題的一種常用手段。我們通常接觸到的建模是爲了解決某個問題而建立的一個數學模型，通過數學計算來分析和預測，找出解決問題的辦法。從理論上說，建立模型是指通過對客觀事物建立一種抽象的方法，用來表徵事物並獲得對事物本身的理解，再把這種理解概念化，並將這些邏輯概念組織起來，形成對所觀察的對象的內部結構和工作原理的便於理解的表達。模型要能夠真實反映客觀事物就需要有一個論證過程，使得建立過程是嚴謹的，並且結果是可追溯和驗證的。對於一種軟件建模方法來說，爲現實世界建立邏輯模型也要是嚴謹的，可追溯和可驗證的，除了描述清楚需求，還要能很容易地將這個模型轉化爲計算機也能夠理解的模型。
第一，UML採用被稱之爲參與者（actor）的元模型作爲信息來源提供者，參與者代表了現實世界的“人”。參與者是模型信息來源的提供者，也是第一驅動者。
第二，UML採用被稱之爲用例（use case）的一種元模型來表示驅動者的業務目標，也就是參與者想要做什麼並且獲得什麼。這個目標就是現實世界中的“事”。
第三，UML通過被稱之爲業務對象模型的視圖來說明在達成這些業務目標的過程中涉及到的事物，業務對象模型則代表了現實世界中的“物”。
第四，第二條中的“事”是怎麼做的，依據什麼規則，則通過被稱之爲業務場景（business scenario）和用例場景（use case scenario）的UML視圖來描繪的，這些場景便是現實世界的“規則”。
UML通過元模型和視圖捕獲現實世界的人，事，物和規則，於是現實信息轉化成了業務模型。
二，從業務模型到概念模型：
邊界類（boundary）
實體類（entity）
控制類（control）
三，從概念模型到設計模型
軟件架構和框架
編程語言
規範或中間件
