什么是可視化建模？

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

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

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

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

    成功三角形

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

 圖1.成功三角形

　　符號(hào)的角色

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

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

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

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

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

    UML的歷史

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

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

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

圖2. UML的組成

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

　　過(guò)程的角色

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

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

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

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

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

　　
    Rational Unified Process

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

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

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

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

　　一個(gè)項(xiàng)目要獲得成功的話，這兩個(gè)方面都必須重視。

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

　　· 初始——指定項(xiàng)目的版本

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

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

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

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

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

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

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

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

　　· 測(cè)試——整個(gè)系統(tǒng)的驗(yàn)證

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

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

    開發(fā)過(guò)程

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

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

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

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

　　Rational Rose工具

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

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

　　總結(jié)

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

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

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

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