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