什么是可視化建模？

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

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

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

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

    成功三角形

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

 圖1.成功三角形

　　符號的角色

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

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

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

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

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

    UML的歷史

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

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

　　當符號都采用了統(tǒng)一的建模語言（UML）的時候“方法的戰(zhàn)爭”才結(jié)束了。“UML是一種用于具體說明、形象化、并記載開發(fā)中的面向?qū)ο笙到y(tǒng)的工作的語言。它表現(xiàn)了Booch、OMT和對象符號，以及大量的其它方法學(xué)（圖2）的最佳觀念的統(tǒng)一。通過統(tǒng)一這些面向?qū)ο蠓椒ㄊ褂玫姆�號，統(tǒng)一的建模語言為基于廣泛的用戶經(jīng)驗基礎(chǔ)形成的面向?qū)ο蠓治龊驮O(shè)計領(lǐng)域中的事實上的標準提供了基礎(chǔ)。”

圖2. UML的組成

　　UML試圖標準化分析和設(shè)計的工作：語義模型（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找到更多關(guān)于UML的信息。

　　過程的角色

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

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

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

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

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

　　
    Rational Unified Process

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

　　Rational Unified Process是沿著這兩個方向構(gòu)建的：

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

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

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

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

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

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

　　· 構(gòu)建——用一系列增加的迭代建立產(chǎn)品

　　· 轉(zhuǎn)換——為用戶團體提供產(chǎn)品（制造、交付和訓(xùn)練）

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

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

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

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

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

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

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

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

    開發(fā)過程

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

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

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

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

　　Rational Rose工具

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

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

　　總結(jié)

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

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

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

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