《UML用户指南第二版》再次温读笔记（一）(downmoon)
前言：最近，花點時間重讀（也不知道是第幾遍了）《UML用戶指南第二版》這本書，感覺雖然對WEB程序開發而言，UML的應用是一個極大的挑戰，然而，其中蘊含的基本原理和指導性卻是歷久彌新，耐人回味。
在此，特地摘錄了部分讓邀月留下印象的章節，以作備忘。
首先，先重復幾個老掉牙的觀點。
?建模的重要性？
如果你想搭一個狗窩，你備好木料、釘子和一些基本工具（如錘子、鋸和卷尺）?，就可以開始工作。從制定一點初步的計劃到完成一個滿足適當功能的狗窩，你 可能不用別人幫助，在幾個小時內就能夠實現。只要狗窩夠大且不太漏水，你的狗就可以安居。如果不制定一個計劃你總是可以返工，或是讓你的狗受些委屈。
如果你想為你的家庭建造一所房子，你備好木料、釘子和一些基本工具，也能開始工作。但這將需要較多的時間，并且你家庭對于房子的需求肯定比狗對于狗窩的需求 要多。在這種情況下，除非你曾經多次建造過房子，否則就需要事先制定出一些詳細的計劃，再開始動工，你才能夠成功。至少你應該繪制一些表明房子是什么樣子 的簡圖。如果你想建造一所能滿足你家庭的需要并符合當地建筑規范的合格房屋，你就需要畫一些建筑圖，使你能想清楚房間的使用目的以及照明、取暖和水管裝置 等實際細節問題。作出這些計劃后，你就能對這項工作所需的時間和物料作出合理的估計。你自己也可能建造出這樣的房屋，但若有其他人協作（可能要將工程中的 許多關鍵部分轉包出去或購買預制的材料）?，效率就會高得多。只要你按計劃行事，不超出時間和財務的預算，你的新房就可能非常令人滿意。如果不制定計劃， 新房就不會完全令人滿意。因此，最好在早期就制定計劃，并謹慎地處理好所發生的變化。
如果你要建造一座高層辦公大廈，若還是先備好木料、釘子 和一些基本工具就開始工作，那將是非常愚蠢的。因為你所使用的資金可能是別人的，他們會對建筑物的規模、形狀和風格作出要求。同時，他們經常會改變想法， 甚至是在工程已經開工之后。由于失敗的代價太高了，因此你必須要做大量的計劃。負責建筑物設計和施工的組織機構是龐大的，你只是其中的一個
組成部 分。這個組織將需要各種各樣的設計圖和模型，以供各方相互溝通。只要你得到了合適的人員和工具，并對把建筑概念轉換為實際建筑的過程進行積極的管理，你將 會建成這座滿足使用要求的大廈。如果你想繼續從事建筑工作，那么你將一定要在使用要求和實際的建筑技術之間做好平衡，并且處理好組員們的休息問題，既不能 把他們置于風險之中，也不能驅使他們
過份辛苦地工作以至于精疲力盡。
奇怪的是，很多軟件開發組織開始想建造一座大廈式的軟件，而在動手處理時卻好像他們正 在倉促地造一個狗窩。有時你是幸運的。如果你在恰當的時間有足夠的合適人員，并且其他的事情都很如意，你可能（僅是可能）使你的團隊推出一個令用戶眼花繚 亂的軟件產品。然而，一般的情況是：你不能得到所有的合適人員（這樣的人員經常供不應求）?，時間并不總是恰當的（昨天可能更好）?，其他的事情也并不盡 如人意（常常由不得自己）?。在因特網時代，對軟件開發的要求正在日益增加，而開發團隊卻還是經常單純地依靠他們唯一真正知道如何做好的一件事—產生程序 代碼。英雄式的編程努力成為這一行業的傳奇，人們似乎經常認為：更努力地工作是面對開發中出現的各種危機的正常反映。然而這未必能產生正確的程序代碼，而 且一些項目是非常巨大的，無論怎樣延長工作時間，也不足以完成所需的工作。
如果你真正想建造一個相當于房子或大廈類的軟件系統，問題可不是僅僅要寫許多軟件。事實上，關鍵是要編出正確的軟件，并考慮怎樣少寫軟件。要生產合格的軟件 就要有一套關于體系結構、過程和工具的規范。即使如此，很多項目開始看起來像狗窩，但隨后發展得像大廈，原因很簡單，它們是自己成就的犧牲品。如果對體系結構、過程或工具的規范沒有作任何考慮，總有一天狗窩會膨脹成大廈，并會由于其自身的重量而倒塌。狗窩的倒塌可能會使你的狗惱怒，同理不成功的大廈將會對大廈的擁有者造成嚴重的影響。不成功的軟件項目失敗的原 因各不相同，而所有成功的項目的成功原因在很多方面都是相似的。一個成功的軟件組織有很多成功的因素，其中共同的一點就是對建模的采用。
建模是一項經過檢驗并被廣為接受的工程技術。我們建立的房屋和大廈的建筑模型能幫助用戶得到實際建筑物的印像。為了分析大風或地震對建筑物造成的影響，我們甚至可以建立數學模型。
建 模不只是用于建筑業。如果不首先構造模型（從計算機模型到物理風洞模型以及與實物大小一樣的原型）?，就裝配新型的飛機或汽車，那簡直是難以想像的。為了 更好地了解系統并與他人交流思想，開發新型的電氣設備（從微處理器到電話交換系統）都需要一定程度的建模。在電影業里，劇本是產品的核心，這也是建模的一 種形式。在社會學、經濟學和商業管理領域中，為了證實理論或用最小限度的風險和代價實驗新的理論，我們也要建模。
那么，模型是什么？簡單地說，模型是對現實的簡化。
模型提供了系統的藍圖。模型既可以包括詳細的計劃，也可以包括從很高的層次考慮系統的總體計劃。一個好的模型包括那些有廣泛影響的主要元素，而忽略那些 與給定的抽象水平不相關的次要元素。每個系統都可以從不同的方面用不同的模型來描述，因而每個模型都是一個在語義上閉合的系統抽象。模型可以是結構性的， 強調系統的組織；它也可以是行為性的，強調系統的動態方面。
我們為什么要建模？一個基本理由是：我們建模是為了能夠更好地理解我們正在開發的系統。
通過建模，要達到四個目的：
1）模型幫助我們按照實際情況或按照我們所需要的樣式對系統進行可視化。
2）模型允許我們詳細說明系統的結構或行為。
3）模型給出了一個指導我們構造系統的模板。
4）模型對我們作出的決策進行文檔化。
【后面討論U?M?L如何完成這四項事情。?】
建模并不只是針對大的系統。甚至像狗窩那樣的軟件也能從一些建模中受益。然而，可以明確地講，系統越大、越復雜，建模的重要性就越大，一個很簡單的原因是：因為我們不能完整地理解一個復雜的系統，所以我們要對它建模。
人對復雜問題的理解能力是有限的。通過建模，縮小所研究問題的范圍，一次只著重研究它的一個方面。這就是Edsger?Dijkstra幾年前講的“各個擊 破”的基本方法，即先把一個要解決的難題劃分成一系列小問題，解決了這些小問題也就解決了這個難題。
此外，通過建?？梢栽鰪娙说闹橇?。一個適當選擇的模型 可以使建模人員在較高的抽象層次上工作。
任何情況下都應該建模的說法也未必盡然。事實上，一些研究指出：大多數軟件組織沒有做正規的建模，即使做了也很少。按項目的復雜性劃分一下建模的使用情況，你還會發現：項目越簡單，采用正規建模的就越少。這 里強調的是“正規化”這個詞。雖然很不正規，但實際上，開發者甚至對一些非常簡單的項目也要做一些建模工作。開發者可能在一塊黑板上或一小片紙上勾畫出他 的想法，以對部分系統進行可視化表示，或者開發組可能使用C?R?C卡片描述一個劇本或機械設計。使用任何一種這樣的模型都沒有什么錯。如果它能行得通， 就有理由使用它。然而，這些非正規的模型經常是太特別了，它沒有提供一種容易讓他人理解的共同語言。建筑業、電機工程業和數學建模都有通用的建模語言，在 軟件開發中使用一種共同的建模語言進行軟件建模也能使開發組織獲益匪淺。
每個項目都能從一些建模中受益。即使在可隨意使用軟件的領域里，由于可視化編程語言的效率，有時扔掉不適合的軟件是更有效的，建模能幫助開發組更好地對 系統計劃進行可視化，這有助于他們正確地實施工作，使開發工作進展得更快。如果根本不建模，項目越復雜，就越有可能失敗或做錯事情。有一個自然趨勢：隨著 時間的推移，所有引人關注的實用系統都變得越來越復雜。雖然你今天可能認為不需要建模，但隨著你的系統的演化，你會對這個決定感到后悔，但那時為時已晚。
????? 再來溫習一下，建模原理
各種工程學科都有其豐富的建模使用歷史。這些經驗形成了建模的四項基本原理，分別敘述如下。
第一，選擇要創建什么模型對如何動手解決問題和如何形成解決方案有著意義深遠的影響。
換句話說，就是要好好地選擇模型。正確的模型將清楚地闡明難以對付的開發問題，提供不能輕易地從別處獲得的洞察力；錯誤的模型將誤導你，使你把精力花在不相關的問題上。對于軟件而言，你所選擇的模型將在很大程度上影響你對世界的看法。如果你以數據庫開發者的觀點建造一個系統，你將可能注意實體 -關系模型，該模型把行為放入觸發器和存儲過程中。如果你以結構化開發者的觀點建造一個系統，你將可能得到以算法為中心的模型，即從處理到處理的數據流。如果你以面向對象開發者的觀點建造一個系統，你將可能得到這樣一個系統，它的體系結構以眾多的類及交互模式（描述了類間的協同工作）為中心。對于一個給定的應用系統和開發氛圍，使用上述的任何一種方法都可能是正確的。經驗表明，在需求易變的系統中面向對象的方法表現得更為出眾，甚至對使用大型數據庫或計算單元的系統也是如此。盡管事實如此，但要強調一點，不同的方法將導致不同種類的系統，并且代價和受益也是不同的。
第二，每一種模型可以在不同的精度級別上表示。
如果你正在建造一座大廈，有時你需要從宏觀上讓投資者看到大廈的樣子，感覺到大廈的總體效果。而有時你又需要認真考慮細節問題，例如，對復雜棘手的管道的鋪設，或對少見的結構件的安置等。對于軟件模型也是如此。有時一個快速簡潔且是可執行的用戶接口模型正是你所需要的，而有時你必須耐著性子對付比特，例如，描述跨系統接口或解決網絡瓶頸問題就是如此。在任何情況下，最好的模型應該是這樣的：它可以讓你根據觀察的角色以及觀察的原因選擇它的詳細程度。分析人員或最終用戶主要考慮“做什么”的問題；開發人員主要考慮“怎樣做”的問題。這兩類人員都要在不同的時間以不同的詳細程度對系統進行可視化。
第三，最好的模型是與現實相聯系的。
如果一所建筑的物理模型不能以與真實的建筑相同的方式作出反映，則它的價值是很有限的。一架飛機的數學模型，如果只是假定了理想條件和完美制造，可能會掩蓋一些潛在的、致命的現實特征。最好是有一個能夠清晰地聯系實際的模型，而當聯系很薄弱時能夠精確地知道這些模型怎樣與現實相脫離。所有的模型都對現實進行了簡化，但有一點要記住，不能簡化掉任何重要的細節。對軟件領域結構化分析的唯一致命弱點是在分析模型和系統設計模型之間沒有基本的聯系。隨著時間的推移，這個不可填充的裂縫會使系統構思階段和實施階段出現不一致。在面向對象的系統中，可以把各個幾乎獨立的系統視圖連結成一個完整的語義整體。
第四，單個模型是不充分的。對每個重要的系統最好用一組幾乎獨立的模型去處理。
如果你正在建造一所建筑物，你會發現沒有任何一套單項設計圖能夠描述該建筑的所有細節。至少你需要基礎計劃、電梯計劃、電氣計劃、供熱計劃和水管裝置計劃。在這里的重要短語是“幾乎獨立的” 。在這個語境中，它意味著各種模型能夠被分別進行研究和構造，但它們仍然是相互聯系的。如同搞建筑一樣，你能夠單獨地研究電氣計劃，但你也能看到它與之對照的基礎計劃，甚至它與水管裝置計劃中的管子排布的相互影響。
面向對象的軟件系統也如此。為了理解系統的體系結構，你需要幾個互補和連鎖的視圖：用況視圖（揭示系統的需求） 、設計視圖（捕獲問題空間和解空間里的詞匯） 、進程視圖（對系統的進程和線程的分布建模） 、實現視圖（描述系統的物理實現）和實施視圖（著重于系統的工程方面的組織） 。每一種視圖都可能有結構方面和行為方面。這些視圖一起從整體上描繪了軟件藍圖。
根據系統的性質，一些模型可能比另一些模型要重要。例如，對于數據密集型系統，表達靜態設計視圖的模型將占主導地位。對于圖形用戶接口密集型系統，靜態和動態用況視圖就顯得相當重要。在實時系統中，動態進程視圖尤為重要。在分布式系統中，例如Web密集型的應用，實現模型和實施模型是最重要的。
當然， 我們要了解的最重要的一點是“面向對象的建模” 。
對于軟件，有幾種建模的方法。最普通的兩種方法是從算法的角度建模和從面向對象的角度建模。
傳統的軟件開發是從算法的角度進行建模，所有的軟件都用過程或函數作為其主要構造塊?，F代的軟件開發采用面向對象的角度進行建模，所有軟件系統都用對象或類作為其主要構造塊。簡單地講，通常要從問題空間或解空間的詞匯中找出對象；類是對具有共同性質的一組對象的描述。每一個對象都有標識（你能夠對它命名，以區別于其他對象） 、狀態（通常有一些數據與它相聯系）和行為（使你能對該對象做某些事，它也能為其他對象做某些事） 。
例如，可考慮把一個簡單的計賬系統的體系結構分成三層：用戶接口層、中間件層和數據庫層。在用戶層，你將找出具體的對象，如按鈕、菜單和對話框。在數據庫層，你將找出具體的對象，如從問題域中找出描述實體的表，它包含顧客、產品和訂單項。在中間件層，你將找出諸如交易、商業規則等對象，以及更高層次上的問題實體，如顧客、產品和訂單。
可以肯定地說，面向對象方法是軟件開發方法的主流部分，其原因很簡單，因為事實已經證明，它適合于在各種問題域中建造各種規模程度和復雜度的系統。此外，當前的大多數程序語言、操作系統和工具在一定的方式上都是面向對象的，并給出更多按對象來觀察世界的理由面向對象的開發為使用構件技術（如Java Beans或 C O M +）裝配系統提供了概念基礎。
選擇按面向對象的方式觀察世界，會產生一系列的問題：什么是優秀的面向對象的體系結構？項目會創造出什么樣的制品？誰創造它們？怎樣度量它們？
對面向對象系統進行可視化、詳述、構造和文檔化正是統一建模語言（ U M L）的目的。
明天繼續讀，呵呵
總結
以上是生活随笔為你收集整理的《UML用户指南第二版》再次温读笔记（一）(downmoon)的全部內容，希望文章能夠幫你解決所遇到的問題。
