大象之UML (一) 準備

開篇之言：
  老子說：大音希聲，大象希形。我的理解大概是，音至極美，聲之其次;象至極大，形之其次;器至極巧，工之其次。

第一章：準備——需要瞭解
一：面向過程還是物件導向。
A：面向過程：
1）前提：面向過程的前提假設是這個過程是穩定的且過程中的每一步都是設定好的。
2）概念：面向過程的方法認為我們的世界是由一個個相互關聯的小系統組成的。且這樣的小系統依據嚴密的邏輯組成的，環環相扣，井然有序。每個小系統有著明確的開始與結束，構成這個系統的各個部分之間有著密不可分的因時關係。
3）特點與困難：這種分析方法在需求複雜較低的時候非常管用，但當考慮的因素太多時，要把所有可能的因素都考慮到，把所有因素的因果關係都分析清楚，再把這個過程類比出來實在是太困難了。而我們的精力有限，計算能力有限，只能放棄對整個過程的瞭解，得閑尋找一個方法，能夠將複雜的系統轉化成一個個我們 可以控制的小單元。如：如果一次成型一輛汽車太過困難，我們可以將汽車分解為很多零件，分步製造，再依據提前設計好的介面把它們安裝起來，形成最終的產品

二：物件導向：（Object Oriented）
將世界看作一個個相互獨立的對象，相互之間並無因果關係，它們平時是“雞犬之聲相聞，老死不相往來”的。只有在某個外部力量的驅動下，對象之間才會依據某種規律相互傳遞資訊。這些互動構成了這個生動世界的一個”過程“。

1）一切都是對象

在物件導向的眼裡，一切有名字的東西都是對象，都應當使用對象的觀點來看待它，分析它。哪怕這個東西的名字叫某某商務程序，它也仍然應當看作是一個對象，而不是一個過程。

2）對象都是獨立的

獨立性是物件導向的一大特點，承認對象的同時就接納了這一觀點。對象與對象之間是天然獨立的，只是在某個特定的情境下，它們的某一個特定的執行個體才相互聯絡在一起。我們擷取和分析對象的手段經常是通過分析某個情境，但是需要知道，對象是離散的，它不是因為該情境而存在的。情境中的對象只是對象“映射”到該情境中的一個側面，我們稱之為對象的執行個體。換言之，通過一個情境，我們僅能得到對象的一個側面的資訊。

3）對象都具有原子性
無論在什麼時候，在分析過程中都應當將對象視為一個不可分割的原子，哪怕這個對象的規模很大。例如在分析一商業過程的時候，對象的規模（粒度）大到如銀行，工廠，商場的程度，不論它有多麼巨大，只要我們認為它是對象，它與其他對象互動就是一具整體，不能分割。
並且在分析過程中，對象總有一個邊界，永遠也不應該打破邊界去窺探對象的內部。就像雞蛋一樣只從外面看你屬性，而不應該開啟去裡邊。

4）對象都是可抽象的
對象有著很多不同的方面。一般來說，對象參與一個情境時會展現出來某一個方面。總可以將對象的某一個方面抽象出來，讓其作為對象的一個代表來參與情境互動。通常這種抽象會以介面來命名。在分析過程中，得到的任何一個對象都有特定的方面可作為抽象。因為對象總是從情境分析中得到的，它在情境中肯定展現了一個方面。對象所具有的方面，或者說對象所參與的情境越多，對象越有抽象價值，反之亦然。

5）對象是有著抽象層次的。層次越高，其描述越粗略但適應能力越廣;層次越低則描述越精確但適應能力越下降。
物件導向與面向過程的根本不同就是：不再把世界看作是一個緊密關聯的系統，而是看成一些相互獨立的小零配件，這個零件依據某種規則群組織起來，完成一個特定的功能。
物件導向的困難：
在現實世界與對象世界之間存在碰上一道鴻溝，它便是抽象：而抽象是物件導向的精髓所在【一種是：把現實世界映射到對象世界的方法。二是：一種從對象世界描述現實世界的方法。三：一種驗證對象世界行為是否正確反映了現實世界的方法。】

三：整合模組化語言（Unified Modeling Language）
特點：
1）統一語言：就是形成標準，使得不同地區，不同文化，不同社會，不同組織的資訊能夠以所有人都明白的表述和所有人都遵從的格式在人群中無障礙地流通。讓人和機器都能讀懂。
2）可視化，在這裡的可視化含義並非指UML的圖形是可以用眼睛看到的，可視化的含義是指，UML通過它的元模型和標記法，把那些通過文字或其他表達方法很難表達清楚的，隱晦的潛台詞用簡單直觀的圖形表達和蚶出來，準確而直觀地撕碎複雜的含義。

四：
1）從現實世界到業務模型（解決了物件導向的第一個需要方法）
建立模型是人們解決現實世界問題的一種常用手段。我們通常接觸到的建模是為瞭解決某個問題而建立的一個數學模型，通過數學計算來分析和預測，找出解決問題的辦法。從理論上說，建立模型是指通過對客觀事物建立一種抽象的方法，用來表徵事物並獲得對事物本身的理解，再把這種理解概念化，並將這些邏輯概念組織起來，形成對所觀察的對象的內部結構和工作原理的便於理解的表達。

  然而我們所處的這個現實世界充滿了豐富多彩但雜亂無章的資訊，要建立一個模型並不容易。建立模型的過程是一個抽象的過程，所以要建立模型，首先是知道如何抽象現實世界。如果我們部在很高手抽象層次，以高度歸納的視角來看這個世界的動作，就會發現現實世界無論多複雜，無論是哪個行業，進無論做什麼業務，其本質無非是由人事物和規則群組成的。人是一切的中心，人要做事，做事就會使用一些物併產生另一些物，同時做事需要新遵循一定的規則。人驅動系統，事體現過程，物記錄結果，規則是控制。建立模型的關鍵就是弄明白有什麼人，什麼人做什麼事，什麼事產生什麼物，中間有什麼規則，再把人事物之間的關係定義貼出來，一個模型也就基本成型了。
其實現過程：
第一：UML採用被稱之為參與者（Actor）的元模型作為資訊來源提供者，參與者代表了現實世界中的“人”。參與者是模型資訊來源的提供者，也是第一驅動者。換句話說，要建立模型的意義完全被參與者決定，所建立的模型也是完全為參與者服務的，參與者 是整個建模過程的中心。之所以這樣做是最終電腦的設計結果如果不符合客戶需求，再好的設計也就等於0.與其在建立電腦系統後因不符合驅動者的意願而推倒重來，還不如一開始就從參與者的角度開始。
第二：UML採用被稱之為用例（use case） 的一種元模型來表示驅動者的營運目標，也就是參與者想要做什麼並且獲得什麼。這個營運目標就是現實世界中的“事”.而這件事是怎麼做，依據什麼規則，則通過被稱之為業務情境（business scenario）和用例情境（use case scenario）這些情境便是現實世界中的“規則”。最後，UML通過被稱之為業務物件模型（business object model）的視圖來說明這些營運目標的過程中涉及到的事物，用邏輯概念來表示它們，並定義它們之間的關係。這便是現實世界中的“物”

2）從業務模型到概念性模型（解決物件導向的第二個方法從對象世界描述現實世界）
業務模型映射並且記錄了現實世界，但這隻是原始的需求資訊，距離可執行代碼還很遙遠，必須把這些內容換成右以指導開發的表達方式。UML通過用被稱之為概念化的過程來建立適合電腦理解和實現的模型，這個模型稱為分析模型（Analysis Model）。
分析需求介於原始需求和電腦實現之間，是一種過渡模型。分析模型向上映射了原始需求，電腦的右執行代碼可以通過分析模型追溯到原始需求；同時，分析模型向下為電腦實現規定了一種高層次的抽象，這種抽象是一種指導，也是一種約束，

分析模型最主要的元模型有：
邊界類（boundary）狹義上說：邊界就是大家熟悉的介面，所有的對電腦的操作都要通過介面進行。從廣義上說：任何一件事物都分為裡面和外面，而外面對裡的事物的任何互動都需要有一個邊界。換句話說，邊界決定了外面能對裡面做什麼“事”。
實體類（entity）就是原始需求中業務模型中的業務實體映射了現實世界中參與者完成營運目標時所涉及的事物。
控制類(Control)邊界與實體都是靜態，本身並不會動作。UML採用控制類來表述原始需求中的動態資訊，即業務或用例情境中的步驟和活動。

由於所有的操作都通過邊界類來進行，能做什麼不能做什麼由邊界決定，所以邊界類實際上代表了原始需求中的“事”;實體類則由業務模型中的領域模型轉化而來，它代表了現實世界中的“物”;控制類則體現了現實世界中的“規則”，也就是定語；

經過了概念性模型的轉換，業務模型看起來對電腦來說可理解了。但是要得到真正可執行檔電腦代碼，還要將概念性模型執行個體化。

三：從概念性模型到設計模型

在上邊建立概念性模型距離可執行代碼已經非常接近了。概念性模型使我們獲得了軟體的藍圖，獲得了建設軟體所需要的所有組成內容以及建設軟體所需要的所有必要的細節。接下來就是設計模型就是要建造零組件，組裝汽車的過程。

四：統一過程簡介
  嚴格來說UML並不是一個方法，非只是一種語言。UML定義了基本元素，定義了文法但是如果要做一個軟體項目，還需要有方法的指導。正如寫文章有方法，有五言律，有七言律一樣，UML也需要有方法的指導來完成一個軟體項目。RUP無疑是目前與UML整合和應用最好，最完整的軟體方法。
RUP(Rational Unified Process)統一過程。統一過程並非是因為UML才誕生的，也不是最近才出來的軟體方法。如果說一曲美妙的樂意是作曲家根據音樂理論進行創作最後用標準的五線譜記錄下來，相信不會有什麼疑問。實際上RUP與UML的關係正類似音樂理論和五線譜的關係。相信有很多讀者並沒有考慮過這個問題，他們會覺的統一過程和UML就是一個東西，統一過程就是UML.但是從本質上說，統一過程和UML是不同的兩個領域。UML是一種語言，用來描述軟體生產過程中要產生的文檔，統一過程則是指導如何產生這些文檔以及這些文檔要講述什麼的方法。

五：建模

一：從問題入手：怎麼建和
首要目標不是要弄清楚業務是如何一步一步完成的，而是要弄清楚有多少業務的參與者？每個參與者的目標是什嗎？
模是什麼
一旦決定了抽象的角度，就確定了一個目標。現在，要做的事情便是找出那些能夠滿足這一目標的事物。這關不容易。有趣的是，我們找出這些事物的過程其實並不是物件導向的，而是過程化的，這是因為要達到一個目標必須要有動作附加在靜態事物上，併產生一定的效果。這樣一來，我們必須要搞清楚 誰發出了什麼動作，作用於什麼事物，產生了怎樣的後果。顯然這種描述方式是過程化的。但是與面向過程方法不同的是，我們描述這個過程化的情境並不是最終目的。也就是說情境類比協助我們找出抽象的對象而情境本身則是這些對象在一定條件下互動的一個特定的結果。當條件變化的時候，情境就會隨之改變。

二：抽象層次：

抽象層次是物件導向方法中極其重要，但是又非常難以掌握的技巧。要學會站在不同的抽象層次考慮問題。抽象層次越高，具體資訊越少，但是概括能力越強;反之亦然。
當我們認識一件事物時，如果描述它的資訊非常之多，我們就不知從哪個主要的方面來瞭解它，於是一個概括的名詞就會幫我們之瞭解，這便是抽象的作用。

三：對象分析方法

概念：要深入瞭解對象，我們經常需要分析很多個該對象的執行個體所參與的情境，以獲得對象的多個側面，再通過歸納整理這些對象的多個執行個體抽象出對象的一般特性。
要使用UML,物件導向的思想和方法是不可迴避的。
1）一切都是對象

在物件導向的眼裡，一切有名字的東西都是對象，都應當使用對象的觀點來看待它，分析它。哪怕這個東西的名字叫某某商務程序，它也仍然應當看作是一個對象，而不是一個過程。

2）對象都是獨立的

獨立性是物件導向的一大特點，承認對象的同時就接納了這一觀點。對象與對象之間是天然獨立的，只是在某個特定的情境下，它們的某一個特定的執行個體才相互聯絡在一起。我們擷取和分析對象的手段經常是通過分析某個情境，但是需要知道，對象是離散的，它不是因為該情境而存在的。情境中的對象只是對象“映射”到該情境中的一個側面，我們稱之為對象的執行個體。換言之，通過一個情境，我們僅能得到對象的一個側面的資訊。

3）對象都具有原子性
無論在什麼時候，在分析過程中都應當將對象視為一個不可分割的原子，哪怕這個對象的規模很大。例如在分析一商業過程的時候，對象的規模（粒度）大到如銀行，工廠，商場的程度，不論它有多麼巨大，只要我們認為它是對象，它與其他對象互動就是一具整體，不能分割。
並且在分析過程中，對象總有一個邊界，永遠也不應該打破邊界去窺探對象的內部。就像雞蛋一樣只從外面看你屬性，而不應該開啟去裡邊。

4）對象都是可抽象的
對象有著很多不同的方面。一般來說，對象參與一個情境時會展現出來某一個方面。總可以將對象的某一個方面抽象出來，讓其作為對象的一個代表來參與情境互動。通常這種抽象會以介面來命名。在分析過程中，得到的任何一個對象都有特定的方面可作為抽象。因為對象總是從情境分析中得到的，它在情境中肯定展現了一個方面。對象所具有的方面，或者說對象所參與的情境越多，對象越有抽象價值，反之亦然。

5）對象是有著抽象層次的。層次越高，其描述越粗略但適應能力越廣;層次越低則描述越精確但適應能力越下降。