1，面向對象和面向過程的例子：
面向過程：
調研需要時，最先弄清楚有多少業務流程，先畫出業務流程圖，
然后順藤摸瓜找出業務流程中每一步參與的部門和崗位，
弄清楚這一步參與者所做的事情和填寫表單的結果，
並關心用戶是如何把結果傳遞下一個環節，這就是面向過程分析。
面向對象：
調研需求時，最先弄清楚有多少個部門，多少個崗位，
並且找個每個部門的業務代表，問他們類似的問題，你平時做什么，都是誰交代做的，
做完之后，你需要通知或者傳遞給誰嗎，做這件事情都需要填寫什么表格嗎，這就是面向對象。
2，UML的產生：
現在面向對象方法的前身通用面向對象開發（GOOD），層次面向對象設計(HOOD)，面向對象結構設計(OOSE)等，面向對象方法設計的統一。
最初叫“統一方法”，后來正式叫“統一建模語言”（uml）,
因為UML本身是一種語言，並沒有包含軟件方法。
UML是一種建模語言，也是由基本詞匯和語義組成。
定義了一些建立模型需要的，表示特定含義的元素，這些元素叫做元模型，也就是基本詞匯，比如用例，類。
還定義了這些元模型互相之間的關系規則，以及如何使用這些元素和規則繪制圖形建立模型來表示現實世界的映射，
這些規則和圖形就是表示法或者說視圖，也就是語法。
UML和其他自然和編程語言的區別是，這種語言是用來寫說明文的，用自然界和計算機邏輯都能理解的表達來說明現實世界。
因為專業化和角色分工，划分為：需求，分析，設計，開發。
為了更好溝通需要一種統一的語言來描述同一個問題，出現了統一建模語言UML.
可視化：
可視化並非只是可見，而是：
UML通過元模型和表示法，將那些通過文字和其他表現方法很難表達清楚，隱晦的前台詞，
用簡單的圖形表達和暴露出來，准確而直觀的表達復雜的含義。
3，從現實世界到業務
建立模型是指通過對客觀事物建立一種抽象的方法，
用來表征事物並獲得對事物本身的理解，
再把這種理解概念化，並將這些邏輯概念組織起來，
形成對所觀察的對象的內部結構和工作原理的便於理解的表達。
ps:世界的模型是，“人” 遵守 “規則” 做 “事” 對某 “物” 產生影響。
UML提供了什么元素為現實世界建立模型。
1，UML采用參與者（actor）作為信息來源的提供者，即“人”，也是驅動着。 建立模型的意義由參與者覺得，也是為參與者服務，參與者是建立模型過程的中心。 2，UML采用用例（use case)的元模型來表示驅動者的業務目標，也就是參與者想做什么獲得什么，即“事”。 怎么做事，需要遵守什么規則，這個"規則"用UML視圖的業務場景（business）和用例場景（use case ）來表示. 最后，UML通過業務對象模型的元素的視圖來說明達到這個業務目標過程所涉及到的事物，即“物”，
用邏輯概念來表示它們，並定義它們之間的關系。
4，從業務模型到概念模型
ps:
概念化的過程就是建立分析模型，
分析模型介於原始需求和實現模型之間，可以追溯到需求，還是計算機實現的一種高層次抽象，
這種抽象對計算機實現可執行代碼設計提供非常容易遵守的指導和約束。
分析模式的最主要的元模型有：
1，邊界類，2，實體類，3，控制類 ps: 類是某種類型，一類的抽象；理解成一種特定屬性的物件，可以是具體是物品，對象，規則
1，邊界類：
ps: 邊界即區別兩個東西各自的范圍。
2，實體類：
ps：具體某個東西，並且可以添加上屬於計算機相關的信息
3，控制類：
ps:控制類即，東西之間的動作行為
有這樣一個游戲：
由4張制片分別寫上：1，什么人；2，在哪里；3，做什么；4，什么物體 隨便組合成一句話。
ps:
形成概念模型后，該模型介與現實業務和計算機思維之間。
補充：
ps:
上面說的分析類，應該是分析模型的各個組成部分。
因為是面向對象分析，一切都可以稱為類
5，從概念模型到設計模型
ps:
設計模型就是具體用軟件相關元素來表示概念模型。
6，面向對象的問題解決
6.1， 面向對象存在的問題：
一切問題都是因為抽象，如何保證抽象的真確性，需要：
6.2，那么UML如何解決的：
1，從現實世界到業務模型
UML采用用例這一關鍵元素捕獲現實世界的人要做的事，
再通過用例場景，領域模型等視圖將現實世界的人，事，物，規則，
這些構成現實世界的元素用UML這種語言描述出來。
而UML本身設計成為一種不但適於現實世界理解，也適於對象世界理解的語言。
即現實世界被我們用一種對象型語言描述。
2，從業務模型到概念模型 當業務模型用分析類來描述的時候，我們實際上采用了對象視角。 用例所代表的現實的業務過程，被“邊界”，“控制”，“實體”以及“包”，“組件”，等概念代替。 而這些概念是可以被計算機理解的，是抽象化了的對象。 現實世界千差萬別的業務，都采用“邊界”，“控制”，“實體”這些固定的元素來描述，也就是說現實具體的業務被抽象成了幾個固定概念。 這些概念還可以用“包”，“組件”等這些現實世界毫不相干的純計算機邏輯術語包裝，這說明概念模型是計算機視角，或者對象視角的， 而且這些對象視角的分析類所描述的信息是從映射了現實世界的業務模型轉化而來的。 即是一種從對象世界來描述現實的方法。
3，從概念模型到設計模型 這是驗證對象世界算法正確反映了現實世界的方法。 “邊界”，“控制”，“實例”這些對象化的概念，雖然是計算機可以理解的，但它並不是真正的對象實例， 即它們並不是可執行代碼，概念模型只是紙上談兵。 真正的對象世界行為是由java類，c++類，EJB等這些可執行代碼構成。 如果缺少了從概念模型到設計模型這個過程，java類，C++類也好，它們的行為是否正確憑什么去驗證呢。 設計模型是概念模型在特定環境和條件下的“實例”化，實例化后的對象行為“執行”了概念模型描述的那些信息， 因此設計得以通過概念模型追溯到元素需求來驗證對象世界是否正確反映了現實世界。
UML是一種建模語言，但我們還需要一種建模指導方法。