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

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

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