??面向?qū)ο蟮木柙诔橄?；面向?qū)ο蟮睦щy在抽象；面向?qū)ο蟮某晒υ谟诔晒Φ某橄?；面向?qū)ο蟮氖≡谟谑〉某橄蟆?br> ??對(duì)象提供了一種處理復(fù)雜性問題的方式。
抽象層次；
面向?qū)ο蟮睦щy：
1）對(duì)象是怎么被抽象出來的？現(xiàn)實(shí)世界和對(duì)象世界看上去差別那么大，為什么要這么抽象而不是那么抽象呢？（Why）
2）對(duì)象世界在于其靈活性，可以任意組合，可是我們?cè)趺粗滥硞€(gè)組合就正好滿足了現(xiàn)實(shí)世界的需求呢？什么樣的組合是好的？什么樣的組合是差的呢？（How）
3）拋開現(xiàn)實(shí)世界，對(duì)象世界是如此的難以理解。如果只給我一個(gè)對(duì)象組合，我怎么才能理解它表達(dá)了怎樣的含義呢？（What）
??實(shí)際工作中，我們常常設(shè)計(jì)出許多類來滿足某個(gè)需求。但是如果問一問為什么要這樣設(shè)計(jì)，為什么是五個(gè)類而不是七個(gè)類？為什么是十個(gè)方法而不是十二個(gè)？能很好回答這個(gè)問題的人不多，絕大部分人的回答是憑檢驗(yàn)。經(jīng)驗(yàn)是寶貴的，可惜經(jīng)驗(yàn)也是靠不住的，憑經(jīng)驗(yàn)的另一個(gè)說法是拍腦袋。從需求到設(shè)計(jì)，從現(xiàn)實(shí)到對(duì)象，那些類的確如孫悟空從石頭里蹦出來一樣，設(shè)計(jì)師一拍腦袋就出來了。
??造成以上問題的原因是因?yàn)楝F(xiàn)實(shí)世界和對(duì)象世界之間存在著一道鴻溝，這道鴻溝的名字叫做抽象。要想跨越這道鴻溝，我們需要：
1）一種把現(xiàn)實(shí)世界映射到對(duì)象世界的方法
2）一種從對(duì)象世界描述現(xiàn)實(shí)世界的方法
3）一種驗(yàn)證對(duì)象世界行為是否正確反映了現(xiàn)實(shí)世界的方法
UML背后所代表的面向?qū)ο蠓治鲈O(shè)計(jì)方法，正好架起了跨越這道鴻溝的橋梁。

??如果你的分析習(xí)慣是在調(diào)研需求時(shí)最先弄清楚有多少業(yè)務(wù)流程，先畫出業(yè)務(wù)流程圖，然后順藤摸瓜，找出業(yè)務(wù)流程中每個(gè)步驟的參與部門或崗位，弄清楚在這一步參與者所做的事情和填寫表單的結(jié)果，并關(guān)心用戶是如何把這份表單傳給下一個(gè)環(huán)節(jié)的。那么很不幸，你還在做面向過程的事情。
??如果你的分析習(xí)慣是在調(diào)研需求時(shí)最先弄清楚有多少部門，多少崗位，然后找到每一個(gè)崗位的業(yè)務(wù)代碼表，問他們類似的問題：你平時(shí)做什么？這件事是誰交代的？做完了你需要通知或傳導(dǎo)給誰嗎？做這件事情你都需要填寫什么表格嗎？那么恭喜你，你已經(jīng)OO啦。

從現(xiàn)實(shí)世界到業(yè)務(wù)模型：建立模型是指通過對(duì)客觀事物建立一種抽象的方法，用來表征事物并獲得對(duì)事物本身的理解，再把這種理解概念化，并將這些邏輯概念組織起來，形成對(duì)所觀察的對(duì)象的內(nèi)部結(jié)構(gòu)和工作原理的便于理解的表達(dá)。模型要能夠真實(shí)反映客觀事物就需要有一個(gè)論證過程，使得模型建立過程是嚴(yán)謹(jǐn)?shù)模⑶医Y(jié)果是可追溯和可驗(yàn)證的。

??現(xiàn)實(shí)世界無論多么復(fù)雜，其本質(zhì)無非是由人、事、物和規(guī)則組成的。人驅(qū)動(dòng)系統(tǒng)，事體現(xiàn)過程，物記錄結(jié)果，規(guī)則是控制。建立模型的關(guān)鍵是弄明白有什么人，什么人做什么事，什么事產(chǎn)生什么物，中間有什么規(guī)則，再把人、事、物之間的關(guān)系定義出來，一個(gè)模型基本就成型了。
??UML采用稱為參與者（actor）的元模型作為信息來源提供者，參與者代表了現(xiàn)實(shí)世界的“人”。UML采用稱為用例（use case）的一種元模型來表示驅(qū)動(dòng)者的業(yè)務(wù)目標(biāo)，也就是參與者想要做什么并且獲得什么。這個(gè)業(yè)務(wù)目標(biāo)就是現(xiàn)實(shí)世界中的“事”。而這件事是怎么做的，依據(jù)什么規(guī)則，則通過稱為業(yè)務(wù)場景（business scenario）和用例場景（use case scenario）的UML視圖來描繪的，這些場景就是現(xiàn)實(shí)世界中的“規(guī)則”。最后，UML通過稱之為業(yè)務(wù)對(duì)象模型（business object model）的視圖來說明在達(dá)成這些業(yè)務(wù)目標(biāo)的過程中涉及到的事物。業(yè)務(wù)對(duì)象模型則代表了現(xiàn)實(shí)世界中“物”。

??從業(yè)務(wù)模型到概念模型：UML通過稱為概念化的過程來建立適合計(jì)算機(jī)理解和實(shí)現(xiàn)的模型，這個(gè)模型稱為分析模型。分析模型介于原始需求和計(jì)算機(jī)實(shí)現(xiàn)之間，是一種過渡模型。分析模型主要的元模型有：
邊界類（boundary）：廣義上說，任何一件事物都分為里面和外面，邊界決定了外面能對(duì)里面做什么“事”。
實(shí)體類（entity）：實(shí)體類可看做是業(yè)務(wù)實(shí)體的實(shí)例化結(jié)果。
控制類（control）：邊界和實(shí)體都是靜態(tài)的，本身并不會(huì)動(dòng)作。UML采用控制類來表述原始需求中的動(dòng)態(tài)信息，即業(yè)務(wù)或用例場景中的步驟和活動(dòng)。從UML觀點(diǎn)來看，邊界類和實(shí)體類之間，邊界類和邊界類之間，實(shí)體類和實(shí)體類之間不能直接相互訪問，他們需要通過控制類來代理訪問要求。

??從概念模型到設(shè)計(jì)模型：概念模型就是繪制汽車需要的所有零部件，并且繪制出如何組裝這些零部件的步驟。設(shè)計(jì)模型的工作就是建造零部件，組裝汽車的過程。大多數(shù)情況，實(shí)現(xiàn)類可簡單的從分析類映射而來。在設(shè)計(jì)模型中，概念模型中的邊界類可被轉(zhuǎn)化為操作界面或系統(tǒng)接口；控制類可被轉(zhuǎn)化為計(jì)算程序或控制程序，例如工作流，算法題等；實(shí)體類可轉(zhuǎn)化為數(shù)據(jù)庫表、XML文檔或其他帶有持久性特征的類。