隻供參考，喜歡請支援正版圖書
1.1 面向過程還是面向對象
我對面向對象程式設計的目标從來就不是複用。相反，對我來說，對象提供了一種處理複雜性問題的方式。這個問題可以追溯到亞裡士多德：您把這個世界視為過程還是對象？在面向對象興起運動之前，程式設計以過程為中心，例如結構化設計方法。然而，系統已經到達了超越其處理能力的複雜性極點。有了對象，我們能夠通過提升抽象級别來建構更大的、更複雜的系統——我認為，這才是面向對象程式設計運動的真正勝利
1.1.1 面向過程方法
如圖1.1所示，計算機通過資料來記錄這個過程的變遷。過程中每一步都會産生、修改或讀取一部分資料。每一個環節完成後，資料将順着過程鍊傳遞到下一部分。當我們需要的最終結果在資料中被反映出來，即達到預期狀态的時候，我們認為這個過程結束了。從圖1.1中也可以看出，銷售定單資料是這個過程的核心。為了能很好地分析這樣的過程，DFD圖被廣泛應用。DFD圖表達了“（從上一步）輸入資料→（在這一步）功能計算→（向下一步）輸出資料”這樣一個基礎單元。例如圖中的“銷售定單”單元，它讀取客戶請求，建立了銷售定單資料；而“财務處理”單元則讀取定購的商品資訊，寫入财務資料……直到“物流”單元将貨物送到消費者手中并将資料寫入銷售定單後，這個過程才宣告結束
由于資料是如此重要，是以資料的正确性和完備性對系統成功與否至關重要。為了更好地管理資料，不至于讓系統運作紊亂，人們通過定義主鍵、外鍵等手段将資料之間的關系描繪出來，結構化地組織它們，利用關系理論，即資料庫的三大範式來保證它們的完備性和一緻性。在面向過程成為主要的軟體方法之後，關系型資料庫得到了極大的發展，針對資料的分析方法ER模型也深入人心，被極為廣泛地使用。
1.1.2 面向過程的困難
其實并非面向過程的方法不正确，隻是因為構成一個系統的因素太多，要把所有可能的因素都考慮到，把所有因素的因果關系都分析清楚，再把這個過程模拟出來實在是太困難了。我們的精力有限，計算能力有限，隻能放棄對整個過程的了解，重新尋找一個方法，能夠将複雜的系統轉化成一個個我們可以控制的小單元。這個方法的轉換正如：如果一次成型一輛汽車太過困難，我們可以将汽車分解為很多零件，分步制造，再依據預先設計好的接口把它們安裝起來，形成最終的産品。
這種把複雜工程轉化成标準零部件的做法，在工業界早已非常普遍，這正是一種面向對象的方法。與過程方法不同的是，汽車不再被看作一個一次成型的整體，而是被分解成了許多标準的功能部件來分步設計制造。我們在市面上看到的每一款汽車，都是基于某個商業政策，由不同的标準零部件組合而成。當市場變化、商業政策變化時，可以通過變更标準零部件來迅速生産一款新車型。
面向過程面對如今這個複雜的世界顯得無能為力，面向對象又如何呢？從下一節開始我們将進入精彩紛呈的面向對象世界，來探詢面向對象方法是如何面對這個複雜世界的。
1.1.3 面向對象方法
面向對象（Object Oriented，簡稱OO）方法将世界看作一個個互相獨立的對象，互相之間并無因果關系，它們平時是“雞犬之聲相聞，老死不相往來”的。隻有在某個外部力量的驅動下，對象之間才會依據某種規律互相傳遞資訊。這些互動構成了這個生動世界的一個“過程”。在沒有外力的情況下，對象則保持着“靜止”的狀态。
圖1.3展示了這樣一個結果，當離散對象們被按規則組合起來以後，就能表達預期的功能。其實世界就是這樣組成的。平時看上去每個對象都互無關系，然而當它們按圖示規則組織起來之後，踩下刹車，汽車便乖乖停住了。
從圖1.3中還可以發現，某些零件不是特殊的隻能用于制動鼓的。如螺絲和螺帽，它們還可以用于别的地方。這是面向對象的一個重要特性：複用。
從圖1.3還可以讀出的另一個重要的資訊是，由于對象是獨立于最終産品的，隻要符合規則要求，這些标準零件就可以替換！我們可以采用鋼制的，也可以采用合金制的；可以采用A工廠生産的，也可以采用B工廠生産的。這使得我們可以在不改變既定目标的情況下替換零件，給我們帶來了極大的靈活性和擴充能力.
1.1.4 面向對象的困難
如果您正被上面的這些問題困擾着，請您不要懷疑是否面向對象錯了。我們把世界看作是由許多對象組成的這并沒有錯，隻是現實世界和對象世界之間存在着一道鴻溝，這道鴻溝的名字就叫做抽象。抽象是面向對象的精髓所在，同時也是面向對象的困難所在。實際上，要想跨越這道鴻溝，我們需要：
■ 一種把現實世界映射到對象世界的方法。
■ 一種從對象世界描述現實世界的方法。
■ 一種驗證對象世界行為是否正确反映了現實世界的方法。
幸運的是，UML，準确地說是UML背後所代表的面向對象分析設計方法，正好架起了跨越這道鴻溝的橋梁。在下一節裡，讓我們帶着疑問，來看看UML是如何解決這些問題的。
1.2 UML帶來了什麼
1.2.1 什麼是UML
為了解決這些困難，一批面向對象的設計方法（OOD方法）開始出現，例如Booch86、GOOD（通用面向對象開發）、HOOD（階層化面向對象設計）、OOSE（面向對象結構設計）等。這些方法可以說是如今面向對象方法的奠基者和開拓者，它們的應用為面向對象理論的發展提供了非常重要的實踐和經驗。同時這些方法也是相當成功的，在不同的範圍内擁有着各自的使用者群。
然而，雖然解決了從設計到開發的困難，随着應用程式的進一步複雜，需求分析成為比設計更為重要的問題。這是因為人們雖然可以寫出漂亮的代碼，卻常常被客戶指責不符合需要而推翻重來。事實上如果不符合客戶需求，再好的設計也等于零。于是OOA（面向對象分析）方法開始走上了舞台，其中最為重要的方法便是UML的前身，即：由Booch創造的Booch方法，由Jacobson創造的OOSE、Martin/Odell方法，Rumbaugh創造的OMT、
Shlaer/Mellor方法。這些方法雖然各不相同，但它們的共同的理念卻是非常相似的。于是三位面向對象大師決定将他們各自的方法統一起來，在1995年10月推出了第一個版本，稱為“統一方法”（Unified Method 0.8）。随後，又以“統一模組化語言”（Unified ModelingLanguage）UML 1.0的正式名稱送出到OMG（對象管理組織），在1997年1月正式成為一種标準模組化語言。之是以改名，是因為UML本身并沒有包含軟體方法，而僅是一種語言，我們将在1.3節統一過程簡介中解釋語言和方法的關系。
1.2.2 統一語言
統一語言的另一個意義是要讓人和機器都能讀懂。好，統一的任務完成了，接下來的任務就是可讀性。如果語言可讀性很差，人們在了解起來同樣會有困難。一門好的語言要能夠讓人們快速了解并留下深刻印象。
我們知道，相對文字和圖形，人腦對圖形的接受能力顯然更強。是以，UML采用了“可視化”的圖形方式來定義語言。
1.2.3 可視化
一幅圖畫可以表達的含義遠遠勝過文字描述，上面的那段話讓我們試着換一種形式來表達，如圖1.5所示。
1.2.4 從現實世界到業務模型
我們所處的這個現實世界充滿了豐富多彩但雜亂無章的資訊，要建立一個模型并不容易。建立模型的過程是一個抽象的過程，是以要建立模型，首先要知道如何抽象現實世界。如果我們站在很高的抽象層次，以高度歸納的視角來看這個世界的運作，就會發現現實世界無論多複雜，無論是哪個行業，無論做什麼業務，其本質無非是由人、事、物和規則組成的。人是一切的中心，人要做事，做事就會使用一些物并産生另一些物，同時做事需要遵循一定的規則。人驅動系統，事展現過程，物記錄結果，規則是控制。建立模型的關鍵就是弄明白有什麼人，什麼人做什麼事，什麼事産生什麼物，中間有什麼規則，再把人、事、物之間的關系定義出來，一個模型也就基本成型了。
那麼UML是不是提供了這樣的元素來為現實世界建立模型呢？是的。
第一，UML采用稱之為參與者（actor）的元模型作為資訊來源提供者，參與者代表了現實世界的“人”。參與者是模型資訊來源的提供者，也是第一驅動者。另外，在這個顧客就是上帝的時代，以參與者也就是“人”為中心還順應了“以人為本”這一時代的要求，更容易獲得客戶滿意度。
第二，UML采用稱之為用例（use case）的一種元模型來表示驅動者的業務目标，也就是參與者想要做什麼并且獲得什麼。這個業務目标就是現實世界中的“事”。而這件事是怎麼做的，依據什麼規則，則通過稱之為業務場景（business scenario）和用例場景（use case scenario）的UML視圖來描繪的，這些場景便是現實世界中的“規則”。
UML通過上面的元模型和視圖捕獲現實世界的人、事、物和規則，于是現實資訊轉化成了業務模型，這也是面向對象方法中的第一步。業務模型真實映射了參與者在現實世界的行為，圖1.6展示了這種映射關系。
1.2.5 從業務模型到概念模型
雖然上一節中現實世界被業務模型映射并且記錄下來，但這隻是原始需求資訊，距離可執行的代碼還很遙遠，必須把這些内容再換成一種可以指導開發的表達方式。UML通過稱之為概念化的過程（Conceptual）來建立适合計算機了解和實作的模型，這個模型稱為分析模型（Analysis Model）。分析模型介于原始需求和計算機實作之間，是一種過渡模型。分析模型向上映射了原始需求，計算機的可執行代碼可以通過分析模型追溯到原始需求；同時，分析模型向下為計算機實作規定了一種高層次的抽象，這種抽象是一種指導，也是一種限制，計算機實作過程非常容易遵循這種指導和限制來完成可執行代碼的設計工作。
事實上分析模型在整個分析設計過程中承擔了很大的職責，起到了非常重要的作用。繪制分析模型最主要的元模型有：
邊界類（boundary） 。邊界是面向對象分析的一個非常重要的觀點。從狹義上說，邊界就是大家熟悉的界面，所有對計算機的操作都要通過界面進行。從廣義上說，任何一件事物都分為裡面和外面，外面的事物與裡面的事物之間的任何互動都需要有一個邊界。比如參與者與系統的互動，系統與系統之間的互動，子產品與子產品之間的互動等。隻要是兩個不同職責的簇之間的互動都需要有一個邊界，換句話說，邊界決定了外面能對裡面做什麼“事”。在後續的章節中，讀者會感受到邊界的重要性，邊界能夠決定整個分析設計的結果。
實體類（entity） 。原始需求中領域模型中的業務實體映射了現實世界中參與者完成業務目标時所涉及的事物，UML采用實體類來重新表達業務實體。實體類可以采用計算機觀點在不丢失業務實體資訊的條件下重新歸納群組織資訊，建立邏輯關聯，添加那些實際業務中不會使用到，但是執行計算機邏輯時需要的控制資訊等。這些實體類可以看作是業務實體的執行個體化結果。
控制類（control） 。邊界和實體都是靜态的，本身并不會動作。UML采用控制類來表述原始需求中的動态資訊，即業務或用例場景中的步驟和活動。從UML的觀點看來，邊界類和實體類之間，邊界類和邊界類之間，實體類和實體類之間不能夠直接互相通路，它們需要通過控制類來代理通路要求。這樣就把動作和物體分開了。考慮下，實際上在現實世界中，動作和物體也是分開描述的。
1.2.6 從概念模型到設計模型
1.2.7 面向對象的困難解決了嗎
1.2.7.1 從現實世界到業務模型
1.2.7.2 從業務模型到概念模型
1.2.7.3 從概念模型到設計模型
1.3 統一過程簡介
1.3.1 RUP是什麼
嚴格說起來UML并不是一個方法，而隻是一種語言。UML定義了基本元素，定義了文法，但是如果要做一個軟體項目，還需要有方法的指導。正如寫文章有文法，有五言律，有七言律一樣，UML也需要有方法的指導來完成一個軟體項目。RUP無疑是目前與UML內建和應用最好、最完整的軟體方法。
RUP（Rational Unified Process）譯為統一過程。統一過程并非是因為UML才誕生的，也不是最近才出來的軟體方法，而是有着很長時間的發展，有着很深的根源。統一過程歸納和整理了很多在實踐中總結出來的軟體工程的最佳實踐，是一個采用了面向對象思想，使用UML作為軟體分析設計語言，并且結合了項目管理、品質保證等許多軟體工程知識綜合而成的一個非常完整和龐大的軟體方法。統一過程經過了三十多年發展，和統一過程本身所推崇的疊代方法一樣，統一過程這個産品本身也經過了很多次的疊代和演進，才最終推出了現在這個版本。圖1.10展示了統一過程的演進過程。
工件：工件也稱為成果物或者制品（Artifact），這與可傳遞物（Deliverable）是有一些差别的。當某一個或某一些工作是最終産品的一部分需要傳遞出去時，才被稱為可傳遞物。而在軟體生産過程中任何留下記錄的事物，都可稱為工件。
1.3.4 RUP與最佳實踐
隻供參考，喜歡請支援正版圖書