為了成功地開發一個項目，你需要正確的過程、工具和符號（注釋）。在本文中作者解釋了UML是如何為你提供符號、Rational統一流程（Unified Process）是如何為你提供正確的流程，以及Rational Rose是如何為你提供使項目成功的工具的。
什麼是可視化建模？
可視化建模（VISUAL MODELING）是利用圍繞現實想法組織模型的一種思考問題的方法。模型對於了解問題、與項目相關的每個人（客戶、行業專家、分析師、設計者等）溝通、模仿企業流程、准備文檔、設計程序和數據庫來說都是有用的。建模促進了對需求的更好的理解、更清晰的設計、更加容易維護的系統。
模型通過過慮非本質的細節信息，成為描述復雜的問題或結構的本質的抽象（abstraction），她使問題更容易理解了。抽象是一種允許我們處理復雜問題的基本能力。千百年以來，工程師、藝術家和工匠一直在實施某項工程之前，先建立模型提煉出它的設計方案。軟件系統的開發也並不例外。為了建立復雜的系統，開發者必須抽象出系統的不同的視圖，使用精確的符號建立模型，驗證這些模型是否滿足系統的需求，並逐漸添加細節信息把這些模型轉變為實現（implementation）。
我們建立復雜系統的模型是因為我們沒法理解整個系統。人類理解復雜性的能力是有限的。這個觀念可以在世界上的建築中看到。如果你希望在後院中建立小屋，你可以立即開始建造；如果你希望建立新房子，你就可能需要一張藍圖了；如果你要建立摩天大樓，你就絕對需要一張藍圖。在軟件的世界中這也是一樣的。由源代碼行或Visual Basic中設計的窗體擔任主角為程序員提供的開發項目的全局視圖是很微不足道的。構造模型允許設計師集中考慮項目中的組成部分如何交互的全局情況，而不會陷入每個組成部分的具體細節信息的泥沼中。
高度競爭的和不斷改變的業務環境導致了復雜性不斷增加，這為系統開發者帶來了獨特的挑戰。模型幫助我們組織、形象化、理解和建立復雜的事物。它們在目前和未來都會幫助我們解決開發軟件遭遇的各種挑戰。
成功三角形
我經常使用圖1所示的成功三角形來解釋成功的項目所需要的組成部分。你需要所有的三個方面——符號、過程和工具。你可以學習一種符號，但是如果不知道如何利用它（過程），你可能會失敗。你可能擁有強大的過程，但是如果不能溝通這些過程（符號），你也可能失敗。最後，如果你不能記載自己的工作文檔（工具），你也可能失敗。
圖1.成功三角形
符號的角色
符號在任何模型中都扮演著重要的部分——它是把過程連接在一起的“粘合劑”。符號有三種角色：
· 它作為傳達決定的語言服務的，它不能明顯地或者不能從代碼自身中推理得到。
· 它提供的語義學對於捕捉所有重要的戰略和戰術決定都是足夠豐富的。
· 它提供了一種具體的形式，足以供人們來思考和工具來操作。
統一的建模語言（UML）提供了非常健全的符號，它從分析的范圍發展到了設計的范圍了。一定的符號元素（例如類、聯系、集合體、繼承）都是在分析中引入的。其它的符號元素（例如保留實現的標識和屬性）都是在設計中引入的。
UML的歷史
在九十年代很多不同的方法學和它們的符號集都被引入市場中。其中最流行的三個是OMT（Rumbaugh）、Booch和OOSE (Jacobson)。每種方法都有自己的價值和重點。OMT在分析方面強大，但是在設計方面比較弱。Booch 1991在設計方面強大但是在分析方面比較弱。Jacobson在行為分析方面強大，但是在其它方面比較弱。
隨著時間的推移，Booch寫了他的第二本書，除了別的內容以外，他還采用了大量的Rumbaugh和 Jacobson提倡的好的分析技術。Rumbaugh出版了一系列文章，形成了我們所知道的OMT-2，它采用了Booch的大量的好的設計技術。這三種技術開始聚合在一起，但是各自仍然有自己獨特的符號。由於符號對不同的人的意味著不同的事物，所以不同的符號的使用給市場帶來了混亂。例如滿圓形（filled circle）在OMT中是多樣性標志，在Booch中卻是集合標志。你可能聽到過用術語“方法的戰爭”來描述這段時間——類到底是雲形還是長方形的？哪個更好？
當符號都采用了統一的建模語言（UML）的時候“方法的戰爭”才結束了。“UML是一種用於具體說明、形象化、並記載開發中的面向對象系統的工作的語言。它表現了Booch、OMT和對象符號，以及大量的其它方法學（圖2）的最佳觀念的統一。通過統一這些面向對象方法使用的符號，統一的建模語言為基於廣泛的用戶經驗基礎形成的面向對象分析和設計領域中的事實上的標准提供了基礎。”
圖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的信息。
過程的角色
成功地開發的項目滿足或超過了客戶的期望，它是用及時並節約的方式開發的，並且對於改變和適應是有彈性的。開發的生命周期必須促進創造和革新，同時開發過程必須被控制和衡量，以確保項目真正地完成了。“創造性對於所有良好構建的面向對象架構的技巧是基本的，但是允許開發者完全無限制地創造會使項目趨向於永遠不會結束。同樣地，當組織開發小組共同工作的時候紀律是必要的，但是太多的紀律將產生官僚作風，這會毀掉各種創新的嘗試”。良好地組織的迭代和增加的生命周期在不影響創造性的情況下提供了必要的控制。
什麼是迭代和增加的開發
在迭代和增加的生命周期中（圖3），開發的進行就是一系列迭代，它們形成最終的系統。每種迭代包括下面的過程組成部分中的一個或多個：業務建模、需求、分析、設計、實現、測試和部署。在生命周期的開始，開發者不能假設所有的需求都是已知的；在所有的階段中必然的改變都是預料中的。
這種類型的生命周期是一種減輕風險的過程。在生命周期的早期評估並區分了技術風險的優先次序，在每個階段的開發中都會調整技術風險。風險被附加到每個階段上，這樣每個階段的成功完成都會減輕附加到它上面的風險。其版本是按計劃預定的，以確保最高的風險被最先處理。采用這種方式建立系統在生命周期的早期就暴露並減輕了系統的風險。這種生命周期方法的結果是風險更少，相關的投資更小。
圖3.迭代和增加的開發
Rational Unified Process
通過使用Rational Unified Process可以支持對迭代和增加的生命周期的控制。它是解決那些集中於需求分析和設計的軟件開發的技術方面和組織方面的問題的指導方針的擴展集合。
Rational Unified Process是沿著這兩個方向構建的：
· 時間——把生命周期分割為階段和迭代
· 過程組成部分——良好地定義的活動的特定工作集合的產品。
一個項目要獲得成功的話，這兩個方面都必須重視。
沿著時間維度構建項目包含了采用下面的基於時間的階段：
· 初始——指定項目的版本
· 詳盡細節——計劃必要的活動和需要的資源；指明特征和設計架構
· 構建——用一系列增加的迭代建立產品
· 轉換——為用戶團體提供產品（制造、交付和訓練）
沿著過程組成部分維度構建項目包含下面的活動：
· 業務建模——希望得到的系統能力和用戶需求的認識
· 需求——擁有一組功能或非功能的需求的系統景象的敘述
· 分析和設計——在實現階段系統如何被了解的描述
· 實現——結果將是可執行的系統的代碼產品
· 測試——整個系統的驗證
· 部署——系統的交付和對客戶的用戶訓練
圖4.過程組成步驟如何應用於某個基於時間的階段
開發過程
典型情況下，過程組成部分維度中的每個活動都應用於基於時間的維度中的每個階段。但是，特定的過程組成部分被應用的程度依賴於開發的階段。例如，你可能決定在初始階段做一次概念原型的校對，因此你做的事情比僅僅捕獲需求要多一些（為了完善原型，你可能要執行分析、設計、實現和測試的事務）。分析過程的組成部分大部分在詳盡細節階段發生。但是，在這個階段完善系統最初的少量迭代也是明智的。典型情況下，這些最初的少量迭代被用於驗證為系統架構所作出的分析決定。
因此，你做的事情不僅僅是分析問題。在開發的構造階段，系統由一組迭代完成。在任何類型的開發結構中，隨著系統的構建，通常會出現一些事態，因此你仍然需要做一些分析。
圖表應該是項目的生命周期的指導。其要點是在編寫代碼的時候，如果你仍然試圖找出要建立什麼樣的系統，你可能就遇到麻煩了。你應該注意，測試應用於整個迭代過程中——你不能等待所有的代碼完成後才檢查它們是否能一起工作。
本文使用了Rational Unified Process的簡化版本，它集中於使用UML來捕獲和記載開發的初始階段和詳盡細節階段中作出的決定。
Rational Rose工具
任何軟件開發的方法都被某種工具最好地支持著。當我最初開始OO建模的時候，我的工具是紙張和鉛筆，我想要更多的工具。現在市場中有了很多工具——從最簡單的繪圖工具到成熟的對象建模工具。本文使用的是Rational Rose。
Rational Rose產品家族被設計為為軟件開發者提供完整的用於開發客戶端/服務器、分布式企業和實時系統環境中滿足實際業務需求的牢固的、高效率的解決方案的可視化建模工具集合。Rational Rose產品共享全體通用的標准，使得希望建立業務流程模型的非程序員和建立應用程序邏輯模型的程序員可以相互理解。Rational Rose工具的評估版可以通過Rational軟件公司Web站點www.rational.com獲取。
總結
可視化建模是利用圍繞現實想法組織模型思考問題的一種方法。模型對於理解問題、溝通、建立企業模型、准備文檔和設計程序和數據庫都是有用的。建模促進了對需求的更好的理解、更好的設計和更容易維護的系統。符號在任何模型中都扮演著重要的部分——它是把過程粘合在一起的“粘合劑”。統一的建模語言提供了豐富的符號，它從分析中發展到設計中。
成功地開發的項目滿足或超越客戶的期望，它是用及時並節約的方式開發的，並且對改變和適應是有彈性的。開發生命周期必須促進創造和革新。良好的管理的迭代和增加生命周期提供了必要的控制，同時不會影響創造性。在迭代和增加的開發生命周期中，開發由一系列的迭代組成，它們將發展成最終的系統。每個迭代包含下面的過程組成部分中的一個或多個：業務建模、需求、分析、設計、實現、測試和部署。
通過使用Rational Unified Process可以支持對迭代和增加的生命周期的控制。它是解決那些集中於需求分析和設計的軟件開發的技術方面和組織方面的問題的指導方針的擴充集合。
Rational Rose產品家族被設計為為軟件開發者提供完整的用於開發客戶端/服務器、分布式企業和實時系統環境中滿足實際業務需求的牢固的、高效率的解決方案的可視化建模工具集合。
