什么是可視化建模？

　　可視化建模（VISUAL MODELING）是利用圍繞現(xiàn)實想法組織模型的一種思考問題的方法。模型對于了解問題、與項目相關的每個人（客戶、行業(yè)專家、分析師、設計者等）溝通、模仿企業(yè)流程、準備文檔、設計程序和數(shù)據(jù)庫來說都是有用的。建模促進了對需求的更好的理解、更清晰的設計、更加容易維護的系統(tǒng)。

　　模型通過過慮非本質的細節(jié)信息，成為描述復雜的問題或結構的本質的抽象（abstraction），她使問題更容易理解了。抽象是一種允許我們處理復雜問題的基本能力。千百年以來，工程師、藝術家和工匠一直在實施某項工程之前，先建立模型提煉出它的設計方案。軟件系統(tǒng)的開發(fā)也并不例外。為了建立復雜的系統(tǒng)，開發(fā)者必須抽象出系統(tǒng)的不同的視圖，使用精確的符號建立模型，驗證這些模型是否滿足系統(tǒng)的需求，并逐漸添加細節(jié)信息把這些模型轉變?yōu)閷崿F(xiàn)（implementation）。

　　我們建立復雜系統(tǒng)的模型是因為我們沒法理解整個系統(tǒng)。人類理解復雜性的能力是有限的。這個觀念可以在世界上的建筑中看到。如果你希望在后院中建立小屋，你可以立即開始建造；如果你希望建立新房子，你就可能需要一張藍圖了；如果你要建立摩天大樓，你就絕對需要一張藍圖。在軟件的世界中這也是一樣的。由源代碼行或Visual Basic中設計的窗體擔任主角為程序員提供的開發(fā)項目的全局視圖是很微不足道的。構造模型允許設計師集中考慮項目中的組成部分如何交互的全局情況，而不會陷入每個組成部分的具體細節(jié)信息的泥沼中。

　　高度競爭的和不斷改變的業(yè)務環(huán)境導致了復雜性不斷增加，這為系統(tǒng)開發(fā)者帶來了獨特的挑戰(zhàn)。模型幫助我們組織、形象化、理解和建立復雜的事物。它們在目前和未來都會幫助我們解決開發(fā)軟件遭遇的各種挑戰(zhàn)。

    成功三角形

　　我經(jīng)常使用圖1所示的成功三角形來解釋成功的項目所需要的組成部分。你需要所有的三個方面——符號、過程和工具。你可以學習一種符號，但是如果不知道如何利用它（過程），你可能會失敗。你可能擁有強大的過程，但是如果不能溝通這些過程（符號），你也可能失敗。最后，如果你不能記載自己的工作文檔（工具），你也可能失敗。

 圖1.成功三角形

　　符號的角色

　　符號在任何模型中都扮演著重要的部分——它是把過程連接在一起的“粘合劑”。符號有三種角色：

　　· 它作為傳達決定的語言服務的，它不能明顯地或者不能從代碼自身中推理得到。

　　· 它提供的語義學對于捕捉所有重要的戰(zhàn)略和戰(zhàn)術決定都是足夠豐富的。

　　· 它提供了一種具體的形式，足以供人們來思考和工具來操作。

　　統(tǒng)一的建模語言（UML）提供了非常健全的符號，它從分析的范圍發(fā)展到了設計的范圍了。一定的符號元素（例如類、聯(lián)系、集合體、繼承）都是在分析中引入的。其它的符號元素（例如保留實現(xiàn)的標識和屬性）都是在設計中引入的。

    UML的歷史

　　在九十年代很多不同的方法學和它們的符號集都被引入市場中。其中最流行的三個是OMT（Rumbaugh）、Booch和OOSE (Jacobson)。每種方法都有自己的價值和重點。OMT在分析方面強大，但是在設計方面比較弱。Booch 1991在設計方面強大但是在分析方面比較弱。Jacobson在行為分析方面強大，但是在其它方面比較弱。

　　隨著時間的推移，Booch寫了他的第二本書，除了別的內容以外，他還采用了大量的Rumbaugh和 Jacobson提倡的好的分析技術。Rumbaugh出版了一系列文章，形成了我們所知道的OMT-2，它采用了Booch的大量的好的設計技術。這三種技術開始聚合在一起，但是各自仍然有自己獨特的符號。由于符號對不同的人的意味著不同的事物，所以不同的符號的使用給市場帶來了混亂。例如滿圓形（filled circle）在OMT中是多樣性標志，在Booch中卻是集合標志。你可能聽到過用術語“方法的戰(zhàn)爭”來描述這段時間——類到底是云形還是長方形的？哪個更好？

　　當符號都采用了統(tǒng)一的建模語言（UML）的時候“方法的戰(zhàn)爭”才結束了。“UML是一種用于具體說明、形象化、并記載開發(fā)中的面向對象系統(tǒng)的工作的語言。它表現(xiàn)了Booch、OMT和對象符號，以及大量的其它方法學（圖2）的最佳觀念的統(tǒng)一。通過統(tǒng)一這些面向對象方法使用的符號，統(tǒng)一的建模語言為基于廣泛的用戶經(jīng)驗基礎形成的面向對象分析和設計領域中的事實上的標準提供了基礎。”

圖2. UML的組成

　　UML試圖標準化分析和設計的工作：語義模型（semantic models）、語法符號（syntactic notation）和圖表（diagrams）。它的第一份公共草案（0.8版本）是在1995年10月引入的。公眾和Ivar Jacobson的反饋都在后面的兩個版本（1996年7月的0.9版本和1996年10月的0.91版本）中包括了。在1997年7月1.0版本被提供給對象管理工作組（OMG）以供標準化。額外的一些增強被集成到UML 1.1版本中，它在1997年9月被提交給OMG。在1997年11月，UML被OMG采用作為標準的建模語言。UML目前的版本是UML 1.4，并且正在朝UML 2.0的方向進展。你可以查看OMG的Web站點www.omg.org找到更多關于UML的信息。

　　過程的角色

　　成功地開發(fā)的項目滿足或超過了客戶的期望，它是用及時并節(jié)約的方式開發(fā)的，并且對于改變和適應是有彈性的。開發(fā)的生命周期必須促進創(chuàng)造和革新，同時開發(fā)過程必須被控制和衡量，以確保項目真正地完成了。“創(chuàng)造性對于所有良好構建的面向對象架構的技巧是基本的，但是允許開發(fā)者完全無限制地創(chuàng)造會使項目趨向于永遠不會結束。同樣地，當組織開發(fā)小組共同工作的時候紀律是必要的，但是太多的紀律將產生官僚作風，這會毀掉各種創(chuàng)新的嘗試”。良好地組織的迭代和增加的生命周期在不影響創(chuàng)造性的情況下提供了必要的控制。

    什么是迭代和增加的開發(fā)

　　在迭代和增加的生命周期中（圖3），開發(fā)的進行就是一系列迭代，它們形成最終的系統(tǒng)。每種迭代包括下面的過程組成部分中的一個或多個：業(yè)務建模、需求、分析、設計、實現(xiàn)、測試和部署。在生命周期的開始，開發(fā)者不能假設所有的需求都是已知的；在所有的階段中必然的改變都是預料中的。

　　這種類型的生命周期是一種減輕風險的過程。在生命周期的早期評估并區(qū)分了技術風險的優(yōu)先次序，在每個階段的開發(fā)中都會調整技術風險。風險被附加到每個階段上，這樣每個階段的成功完成都會減輕附加到它上面的風險。其版本是按計劃預定的，以確保最高的風險被最先處理。采用這種方式建立系統(tǒng)在生命周期的早期就暴露并減輕了系統(tǒng)的風險。這種生命周期方法的結果是風險更少，相關的投資更小。

圖3.迭代和增加的開發(fā) 

　　
    Rational Unified Process

　　通過使用Rational Unified Process可以支持對迭代和增加的生命周期的控制。它是解決那些集中于需求分析和設計的軟件開發(fā)的技術方面和組織方面的問題的指導方針的擴展集合。

　　Rational Unified Process是沿著這兩個方向構建的：

　　· 時間——把生命周期分割為階段和迭代

　　· 過程組成部分——良好地定義的活動的特定工作集合的產品。

　　一個項目要獲得成功的話，這兩個方面都必須重視。

　　沿著時間維度構建項目包含了采用下面的基于時間的階段：

　　· 初始——指定項目的版本

　　· 詳盡細節(jié)——計劃必要的活動和需要的資源；指明特征和設計架構

　　· 構建——用一系列增加的迭代建立產品

　　· 轉換——為用戶團體提供產品（制造、交付和訓練）

　　沿著過程組成部分維度構建項目包含下面的活動：

　　· 業(yè)務建模——希望得到的系統(tǒng)能力和用戶需求的認識

　　· 需求——擁有一組功能或非功能的需求的系統(tǒng)景象的敘述

　　· 分析和設計——在實現(xiàn)階段系統(tǒng)如何被了解的描述

　　· 實現(xiàn)——結果將是可執(zhí)行的系統(tǒng)的代碼產品

　　· 測試——整個系統(tǒng)的驗證

　　· 部署——系統(tǒng)的交付和對客戶的用戶訓練

圖4.過程組成步驟如何應用于某個基于時間的階段 

    開發(fā)過程

　　典型情況下，過程組成部分維度中的每個活動都應用于基于時間的維度中的每個階段。但是，特定的過程組成部分被應用的程度依賴于開發(fā)的階段。例如，你可能決定在初始階段做一次概念原型的校對，因此你做的事情比僅僅捕獲需求要多一些（為了完善原型，你可能要執(zhí)行分析、設計、實現(xiàn)和測試的事務）。分析過程的組成部分大部分在詳盡細節(jié)階段發(fā)生。但是，在這個階段完善系統(tǒng)最初的少量迭代也是明智的。典型情況下，這些最初的少量迭代被用于驗證為系統(tǒng)架構所作出的分析決定。

　　因此，你做的事情不僅僅是分析問題。在開發(fā)的構造階段，系統(tǒng)由一組迭代完成。在任何類型的開發(fā)結構中，隨著系統(tǒng)的構建，通常會出現(xiàn)一些事態(tài)，因此你仍然需要做一些分析。

　　圖表應該是項目的生命周期的指導。其要點是在編寫代碼的時候，如果你仍然試圖找出要建立什么樣的系統(tǒng)，你可能就遇到麻煩了。你應該注意，測試應用于整個迭代過程中——你不能等待所有的代碼完成后才檢查它們是否能一起工作。

　　本文使用了Rational Unified Process的簡化版本，它集中于使用UML來捕獲和記載開發(fā)的初始階段和詳盡細節(jié)階段中作出的決定。

　　Rational Rose工具

　　任何軟件開發(fā)的方法都被某種工具最好地支持著。當我最初開始OO建模的時候，我的工具是紙張和鉛筆，我想要更多的工具。現(xiàn)在市場中有了很多工具——從最簡單的繪圖工具到成熟的對象建模工具。本文使用的是Rational Rose。

　　Rational Rose產品家族被設計為為軟件開發(fā)者提供完整的用于開發(fā)客戶端/服務器、分布式企業(yè)和實時系統(tǒng)環(huán)境中滿足實際業(yè)務需求的牢固的、高效率的解決方案的可視化建模工具集合。Rational Rose產品共享全體通用的標準，使得希望建立業(yè)務流程模型的非程序員和建立應用程序邏輯模型的程序員可以相互理解。Rational Rose工具的評估版可以通過Rational軟件公司W(wǎng)eb站點www.rational.com獲取。

　　總結

　　可視化建模是利用圍繞現(xiàn)實想法組織模型思考問題的一種方法。模型對于理解問題、溝通、建立企業(yè)模型、準備文檔和設計程序和數(shù)據(jù)庫都是有用的。建模促進了對需求的更好的理解、更好的設計和更容易維護的系統(tǒng)。符號在任何模型中都扮演著重要的部分——它是把過程粘合在一起的“粘合劑”。統(tǒng)一的建模語言提供了豐富的符號，它從分析中發(fā)展到設計中。

　　成功地開發(fā)的項目滿足或超越客戶的期望，它是用及時并節(jié)約的方式開發(fā)的，并且對改變和適應是有彈性的。開發(fā)生命周期必須促進創(chuàng)造和革新。良好的管理的迭代和增加生命周期提供了必要的控制，同時不會影響創(chuàng)造性。在迭代和增加的開發(fā)生命周期中，開發(fā)由一系列的迭代組成，它們將發(fā)展成最終的系統(tǒng)。每個迭代包含下面的過程組成部分中的一個或多個：業(yè)務建模、需求、分析、設計、實現(xiàn)、測試和部署。

　　通過使用Rational Unified Process可以支持對迭代和增加的生命周期的控制。它是解決那些集中于需求分析和設計的軟件開發(fā)的技術方面和組織方面的問題的指導方針的擴充集合。

　　Rational Rose產品家族被設計為為軟件開發(fā)者提供完整的用于開發(fā)客戶端/服務器、分布式企業(yè)和實時系統(tǒng)環(huán)境中滿足實際業(yè)務需求的牢固的、高效率的解決方案的可視化建模工具集合。