為了提高生產(chǎn)效率并獲得成功，開發(fā)團隊的成員需要擁有通用過程，通用的術(shù)語表和相應(yīng)的支持工具。這篇文章討論了UML如何能夠幫助你達到這個目標。
 
　　在現(xiàn)代的軟件開發(fā)中存在這一種基本上相互矛盾的論點。一方面組織面對著更加快速的響應(yīng)市場的要求;另一方面，在相同的組織中還面臨著以更低的成本交付高質(zhì)量系統(tǒng)的壓力。在這兩者之間維持一個平衡是非常難的：匆忙的將軟件系統(tǒng)推向市場，系統(tǒng)的質(zhì)量勿庸置疑的會受到指責(zé);而僅僅考慮質(zhì)量問題，你也可能因為花費了過長的時間交付系統(tǒng)給用戶而導(dǎo)致失敗。
 
　　隨著軟件開發(fā)的本質(zhì)發(fā)生的改變，融合這對相互矛盾的論點也成為了現(xiàn)實。從歷史的觀點來看，許多信息系統(tǒng)從體系架構(gòu)上是非常簡單的：應(yīng)用被建立在中間層的基礎(chǔ)上，中間層典型的封裝了商業(yè)規(guī)則和數(shù)據(jù)訪問，并且中間層被建立在永久存儲之上，通常使用關(guān)系型的數(shù)據(jù)庫系統(tǒng)。關(guān)系型數(shù)據(jù)庫(或者數(shù)據(jù)庫)本質(zhì)上是系統(tǒng)的中心，它獲取系統(tǒng)問題領(lǐng)域的詞匯表并作為系統(tǒng)狀態(tài)的存儲服務(wù)。客戶端/服務(wù)器架構(gòu)的出現(xiàn)幫助了劃分3層分離的結(jié)構(gòu)，對于組織來說可以以一種可控的方式來應(yīng)對系統(tǒng)相應(yīng)的變化。尤其是，應(yīng)用要能被快速的創(chuàng)建和修改，同時還要保存系統(tǒng)的狀態(tài)，新的業(yè)務(wù)規(guī)則應(yīng)該能夠被引入而不會使系統(tǒng)受到影響，并且數(shù)據(jù)應(yīng)該可以隨著時間的流逝以一種新的或未預(yù)期的方式被挖掘。已被證明的且穩(wěn)定的體系架構(gòu)指引著很多組織以相應(yīng)的方式構(gòu)建他們的團隊：分析人員與領(lǐng)域?qū)＜乙黄鸸ぷ鲗⒂脩舻男枰b化成需求，數(shù)據(jù)建模人員構(gòu)建滿足這些客戶功能需求的領(lǐng)域模型，應(yīng)用開發(fā)人員通過快速的構(gòu)建和分解來建立滿足系統(tǒng)行為需求的的新系統(tǒng)。
 
　　然而，隨著Web的出現(xiàn)，軟件開發(fā)的世界發(fā)生的翻天覆地的變化。在傳統(tǒng)的客戶端/服務(wù)器形式的系統(tǒng)中，一個系統(tǒng)典型的擁有可控數(shù)量的用戶，通常用戶的數(shù)量在幾百到幾千人之間;而在Web系統(tǒng)的情況下，一個系統(tǒng)也許會有幾百萬的用戶，這些用戶中的很多都是不在軟件開發(fā)組織的控制之下的。在傳統(tǒng)的客戶端/服務(wù)器的系統(tǒng)中，從應(yīng)用到數(shù)據(jù)的概念性的距離是非常小的;而在Web環(huán)境下，多數(shù)系統(tǒng)是由成千上萬的移動的部分組成，這些移動部分通常是一些腳本的和一些編譯過的代碼，通過使用這些機制，使得應(yīng)用和關(guān)系型的存儲在距離上是相當(dāng)遠的。在傳統(tǒng)的客戶機/服務(wù)器系統(tǒng)中，變化是不可避免的，但變化可以被適當(dāng)?shù)墓芾恚赪eb環(huán)境下，變化是連續(xù)的，并且變化發(fā)生在系統(tǒng)體系架構(gòu)和實現(xiàn)技術(shù)的每一個層面上。在傳統(tǒng)的客戶機/服務(wù)器系統(tǒng)中，成功的開發(fā)并發(fā)布系統(tǒng)的涉眾數(shù)量相對來說是比較少的;而在Web環(huán)境下，有很多新的涉眾參與到了系統(tǒng)的開發(fā)當(dāng)中，從內(nèi)容的創(chuàng)建者到信息架構(gòu)到網(wǎng)絡(luò)設(shè)計，所有這些人都必須與傳統(tǒng)的軟件開發(fā)團隊共同工作以克服軟件開發(fā)中的矛盾。
 
　　成功的處理軟件開發(fā)中的矛盾的組織與哪些在這方面失敗的組織在組織運作的方法上存在著本質(zhì)的不同。特別的，高生產(chǎn)效率的組織將軟件開發(fā)看作為一項團隊運動，在這樣的組織中很多不同的對系統(tǒng)的開發(fā)和部署作出貢獻的涉眾通過使用通用的過程，通用的表達語言并使用支持和鼓勵與過程和語言相關(guān)的最佳實踐的工具來實現(xiàn)統(tǒng)一。
 
　　Rational統(tǒng)一過程(RUP)是一種已經(jīng)被證明對大多數(shù)面臨著軟件開發(fā)中的矛盾的組織來說是非常有用的。RUP是一種鼓勵以增量和迭代的方式交付系統(tǒng)的可執(zhí)行版本的過程。RUP是風(fēng)險和用例驅(qū)動的，這就意味著RUP傾向盡早的識別和處理防礙系統(tǒng)成功的風(fēng)險，并且它的迭代是被來自于系統(tǒng)不同涉眾透視圖的用例指導(dǎo)的。此外，RUP是一種架構(gòu)先行的過程，無論在哪里，系統(tǒng)的架構(gòu)都是在早期就被穩(wěn)定下來的，這樣便可以建立和驗證策略性的設(shè)計決定，然后在每一個新的迭代中進行不斷的細化。
 
　　在傳統(tǒng)的情況下，許多大數(shù)據(jù)系統(tǒng)在他們的實現(xiàn)上是使用Cobol這樣的在當(dāng)時具有統(tǒng)治地位的語言編寫的。但隨著Web的出現(xiàn)，一切都發(fā)生了變化，甚至一些遺留系統(tǒng)也已經(jīng)被移植到了Web之上。在Web環(huán)境中，一個大數(shù)據(jù)的系統(tǒng)可以使用Cobol，C++ 或Java來編寫服務(wù)器端的程序，使用教本語言(如Perl, VBScript, JavaScript)，第四代編程語言(如：Delphi )和經(jīng)典的語言(如：Visual Basic 和 Java)來實現(xiàn)客戶端的程序。象XML語言在這里很好的扮演了這樣一個角色：XML是一種在Web上表示數(shù)據(jù)結(jié)構(gòu)的通用語言。除了面臨著一些編程語言的選擇，企業(yè)開發(fā)團隊也必須在各式各樣的技術(shù)中作出正確的選擇，如Microsoft WinDNA and Sun的 EJB，而這些技術(shù)呈現(xiàn)給開發(fā)人員不同的編程模型。
 
　　對于成功的組織，使企業(yè)開發(fā)團隊的成員使用相同的聲音進行交流是最基本的：不同的涉眾針對系統(tǒng)的設(shè)計和實現(xiàn)有不同的視圖，并且如果他們不使用同一種通用的詞匯表和表達語言，統(tǒng)一團隊的活動是不可能的。
 
　　這是統(tǒng)一建模語言(UML)的角色之一，UML是對象管理組織(OMG)的一項標準。UML是一種可視化的詳細的構(gòu)建并文檔化軟件系統(tǒng)工作產(chǎn)物的圖形化語言。
 
　　對于一個建筑項目，你不能僅用藍圖中的單一一頁來呈現(xiàn)，詳細描述，構(gòu)建和文檔化一個高大建筑。軟件也是如此：為了獲得所有的策略性的系統(tǒng)設(shè)計決策，你需要幾個不同的系統(tǒng)體系架構(gòu)的視圖，每一個視圖針對者團隊中的不同涉眾。見圖1所示，對于下面描述的軟件系統(tǒng)來說，存在著五個非常重要的視圖。
 
　　

　　圖1：用例視圖
 
　　系統(tǒng)的用例視圖是面向指定的最終用戶的，這個視圖獲取了系統(tǒng)需要擁有的功能。這個視圖對測試人員也是同樣重要的。對于測試人員來說用例形成了對每一個個執(zhí)行版本回歸測試的基礎(chǔ)。
 
　　系統(tǒng)的邏輯視圖是分析人員和設(shè)計人員最感興趣的，邏輯視圖與實現(xiàn)了來自于第一個視圖的用例的架構(gòu)上的重要機制一起的描述了系統(tǒng)的問題領(lǐng)域的詞匯表。在這個視圖中，你將找到描述問題領(lǐng)域的應(yīng)用，數(shù)據(jù)和業(yè)務(wù)模型，它邏輯視圖與類，包，子系統(tǒng)和協(xié)作一起實現(xiàn)了系統(tǒng)的用例。
 
　　系統(tǒng)的過程視圖描述了系統(tǒng)對過程和任務(wù)的分解，并且描述了并發(fā)元素的通訊和同步。這個視圖對于從事整個系統(tǒng)的性能可測量性的系統(tǒng)集成人員來說是最重要的。系統(tǒng)的實現(xiàn)視圖捕獲了被系統(tǒng)的編程人員產(chǎn)生的工作產(chǎn)物，這個視圖用于建?？蓤?zhí)行組件和相應(yīng)的源文件以及形成可執(zhí)行部分的內(nèi)容。這個視圖位于項目配置管理實踐的中心，以及描述了那些在每一個迭代中被組裝成為可執(zhí)行版本的組件。
 
　　系統(tǒng)的部署視圖是項目的系統(tǒng)和網(wǎng)絡(luò)工程師最關(guān)心的視圖，系統(tǒng)和網(wǎng)絡(luò)工程師負責(zé)系統(tǒng)硬件拓撲以及交付和安裝搭建系統(tǒng)。這個視圖描述了系統(tǒng)的物理網(wǎng)絡(luò)配置。
 
　　所有的這些視圖都是用UML來表示的。例如，類圖可以被用來顯示邏輯視圖的靜態(tài)部分，組件圖可以被應(yīng)用到組件視圖。每一個視圖的動態(tài)元素可以通過使用UML的行為圖中的任何一種來獲取，象交互圖和狀態(tài)表圖。此外，通過UML的擴展機制，對語言進行相應(yīng)的調(diào)整以使它可以表達特定領(lǐng)域的需求是可能的。比如，Jim Conallen創(chuàng)建的Web應(yīng)用擴展就是針對以Web應(yīng)用系統(tǒng)為中心的UML的擴展應(yīng)用。通過使用這個藍圖的通用語言，不同的涉眾可以貢獻他在特定領(lǐng)域的專家建議，同時使用UML可以與其他的涉眾進行良好的交流。
 
　　使開發(fā)團隊使用同一種聲音的價值對于哪些大數(shù)據(jù)應(yīng)用來說格外的明顯。無論在哪，數(shù)據(jù)庫的設(shè)計人員都必須與系統(tǒng)分析人員和應(yīng)用的開發(fā)人員一起工作以構(gòu)建系統(tǒng)。傳統(tǒng)的情況下，系統(tǒng)的數(shù)據(jù)中心部分使用實體-關(guān)系(ER)技術(shù)來進行建模。ER方法對開發(fā)團體的服務(wù)非常的好，但是，開發(fā)世界已經(jīng)發(fā)生了顯著的變化，以至ER方法已經(jīng)能很難作為數(shù)據(jù)庫設(shè)計人員與其他涉眾進行交流的工具，并且它也很難再來表達目前大數(shù)據(jù)系統(tǒng)的語義。正如Dorsey 和 Hudicka所說的那樣，"有一種強制的需要應(yīng)用如此靈活的，有活力的并且是面向?qū)ο蟮腢ML來代替當(dāng)前業(yè)界標準的ER建模"。事實上，這也是被Rational Software開發(fā)的UML在數(shù)據(jù)側(cè)面擴展(data profile extension)方面的真正意圖。
 
　　UML在語義上比傳統(tǒng)的ER技術(shù)更加具有表達力。使用UML你不但可以建模與ER方法相同的元素，你可以建模其他種類的比如行為特征的關(guān)系(比如關(guān)聯(lián))。雖然UML的符號比傳統(tǒng)的ER符號有所不同，但是對于使用ER建模的老手來說，轉(zhuǎn)到UML上并不是非常的困難。見圖2。
 
　　

　　圖2：從ER符號轉(zhuǎn)換到UML符號
 
　　為了詳細說明一個數(shù)據(jù)模型，你可以簡單的使用UML類圖。為了進一步獲取數(shù)據(jù)庫的邏輯設(shè)計，你可以使用UML類圖中的作為表的類原型。對于每一個表，你可以對它的列(作為屬性，包括作為主鍵和索引的屬性)和觸發(fā)器(作為操作)進行建模。為了獲取數(shù)據(jù)庫的物理元素，你可以使用UML組建圖中的數(shù)據(jù)庫原型組件。無論是在邏輯視圖還是物理視圖中，你當(dāng)然具有UML對建模關(guān)系(如，關(guān)聯(lián)和繼承)和行為(如，通過交互圖或狀態(tài)表圖)的全部的表達能力。
 
　　以這種方式，你就可以將你的系統(tǒng)數(shù)據(jù)模型和需求放到完成的項目中，跨職能的統(tǒng)一團隊的成員形成了一種協(xié)作的力量。通過使用象Rational Rose Data Modeler這樣的工具支持這些模型，之前數(shù)據(jù)團隊中分離的成員現(xiàn)在可以非常容易的訪問整個項目需求上下文中對數(shù)據(jù)的需求，并且可以在應(yīng)用模型和與系統(tǒng)相關(guān)的需求文本和屬性的用例模型之間對數(shù)據(jù)模型進行跟蹤。相似的，分析人員與應(yīng)用的開發(fā)人員可以更好的與數(shù)據(jù)小組進行交流，因為他們使用同一種公用的表達語言。因為UML的語義是非常豐富的，它可以在系統(tǒng)中被用來呈現(xiàn)和說明集成點。這也使得跟蹤象模型向關(guān)系數(shù)據(jù)模型的移植變得可能。在支持數(shù)據(jù)庫逆向工程的工具出現(xiàn)時，對于用戶來說基于數(shù)據(jù)庫結(jié)構(gòu)通過正向工程來創(chuàng)建數(shù)據(jù)模型或者基于數(shù)據(jù)模型通過逆向工程來創(chuàng)建數(shù)據(jù)庫將成為可能。所有與數(shù)據(jù)小組相關(guān)的語義-表，列，約束，索引，觸發(fā)器以及更多-都能通過這樣的轉(zhuǎn)換被保存。
 
　　在協(xié)調(diào)軟件開發(fā)中矛盾的方式下構(gòu)建一個企業(yè)級的軟件系統(tǒng)是非常難的，你必須在快速的開發(fā)壓力與高質(zhì)量之間進行權(quán)衡。使用UML對系統(tǒng)的工作產(chǎn)物進行可視化，描述和文檔化可以使開發(fā)組織中的工作在一個團隊中的涉眾人員使用同一種語言和工具完成工作。
 
　　注釋:這篇文章最初發(fā)表在 Rational Developer Network
 
　　關(guān)于作者
 
　　Grady Booch，Grady Booch在軟件架構(gòu)，建模和軟件工程過程領(lǐng)域的創(chuàng)新性工作是被國際公認的。他的工作已經(jīng)改經(jīng)了開發(fā)人員世界的效力。Grady是統(tǒng)一建模語言的創(chuàng)始人，并且他也是一些Rational產(chǎn)品，包括Rational Rose，業(yè)界領(lǐng)先的可視化開發(fā)工具的創(chuàng)始人。Grady是六本最熱銷的書籍的作者，他也發(fā)表了幾百篇關(guān)于軟件工程的技術(shù)文章，他在世界各地進行講演和咨詢。Grady是IBM Rational的首席科學(xué)家。