UML規(guī)約的新版本將很快提交給OMG，新的改動希望能夠簡化模型驅(qū)動的開發(fā)。

Rational公司新加坡分部的高級軟件工程專家，Mark Hermeling認(rèn)為：UML2.0根據(jù)工業(yè)界使用UML1.x的經(jīng)驗作了相應(yīng)改進，目的就是為了幫助簡化模型驅(qū)動的開發(fā)。

UML的目前版本是1.4,它提供了方便開發(fā)團隊在分析設(shè)計、需求管理等活動中進行交流的整套工具，以及一個軟件開發(fā)生命周期模型。

有人將UML描述為交流的符號集，這意味著可以直接寫在紙上或者畫在白板上。但大多數(shù)用戶還是選擇使用工具，目前業(yè)界的ling dao是Rational，它和其它的工具提供商一起提供各種UML產(chǎn)品。

1996年，UML剛誕生的時候，廣受歡迎。在UML之前，建模方法非常多，這大大阻礙了基于模型的設(shè)計，而UML實現(xiàn)了建模語言一定程度上的統(tǒng)一。

進行面向?qū)ο笤O(shè)計的時候，第一步就要對現(xiàn)實世界進行建模，UML正是為之定義的一套標(biāo)準(zhǔn)符號，它由三種面向?qū)ο蟮姆治鲈O(shè)計方法發(fā)展并整合而來：Grady Booch 描述對象及其相互關(guān)系的方法、James Rumbaugh的對象建模技術(shù)(OMT) 以及 Ivar Jacobson的方法，在Ivar Jacobson的方法中引入了use case方法的使用。

經(jīng)過多年的發(fā)展，在Rational 公司的Booch、Rumbaugh、Jacobson 三友以及其它專家的努力下，UML中還融入了很多其它的思想，現(xiàn)在，UML已經(jīng)成為OMG認(rèn)可的標(biāo)準(zhǔn)。

盡管UML只是幫助參與開發(fā)的所有人員對模型進行交流的一套符號系統(tǒng)。但Martin Fowler在其著作《UML Distilled》中指出，UML是由描述開發(fā)過程和有關(guān)模型的使用的方法論發(fā)展而來的。盡管目前沒有被廣泛接受的統(tǒng)一過程，UML的使用者使用的方法實際上都非常相似。UML規(guī)約中有關(guān)建模的概念是對象、類、關(guān)聯(lián)、職責(zé)、活動、接口、use case、包、順序、協(xié)作和狀態(tài)。

在使用當(dāng)前版本進行UML模型驅(qū)動的架構(gòu)時，使用者發(fā)現(xiàn)還缺少一些支持，如bug修復(fù)等，UML2.0中將增加這部分內(nèi)容，它將成為適用于企業(yè)建模和數(shù)據(jù)建模的龐大而靈活的符號語言。在UML2.0中，將對語意部分進行增強，這一點可以幫助UML模型更好地生成代碼，以得到更加實用的模型。在即將推出的版本中，還將包括增強的組件處理、對商業(yè)過程模型的支持，并更好地支持元數(shù)據(jù)交換。這些努力都是為了使UML作為一種勝過大多數(shù)文本語言的高層次的語言，能夠生成代碼和進行反工程，甚至直接生成某些可執(zhí)行的UML模型。

目前，在各種工具之間進行模型交換時，只能保存非圖形化的信息，而象繪制的各種圖、尺寸、坐標(biāo)這樣的內(nèi)容都會丟失。在UML2.0中，將提供保留圖形信息的能力。

來自Rational公司的Hermeling認(rèn)為，工程師與開發(fā)人員將越來越多地看到對建模的需求。他認(rèn)為，對于一個較大的開發(fā)團隊來說，需要有一個可視化的模型以保證所有人員都能理解總體的設(shè)計思路，建模的需求是顯而易見的。

利用業(yè)務(wù)過程建模，應(yīng)用UML可以得到業(yè)務(wù)的可視化模型，其作用類似于建筑工程中的結(jié)構(gòu)圖。這個可視化模型可以使你在構(gòu)造整個軟件系統(tǒng)之前，就可以理解并預(yù)知設(shè)計的一些關(guān)鍵特性，判斷設(shè)計是否可行。事實上，除了軟件工程，在眾多工程領(lǐng)域中，建模都是非常關(guān)鍵的規(guī)避風(fēng)險的技術(shù)。

但是，在Fowler眼里，軟件工程和其它工程是不同的。

首先，對建筑工程來說，工程師一般都有多年的經(jīng)驗并且對所用的各種工程符號了如指掌，而UML的設(shè)計可能在紙上畫出來看著很好，真正編程時卻會發(fā)現(xiàn)很多問題。另外，在建筑工程上，關(guān)鍵設(shè)計都是可以經(jīng)過數(shù)學(xué)分析進行驗證的；而在UML設(shè)計中，類似的手段只有同行評審，雖然有一定作用，卻并不能避免錯誤的發(fā)生。

另外，在成本比例方面，軟件設(shè)計和其它領(lǐng)域的工程也是截然不同的。舉修橋的例子來說吧，設(shè)計成本可能也就占全部成本的 10％,而在軟件設(shè)計中，這個比率是50％。

UML最早是由Rational公司提出的，但已經(jīng)被很多公司使用，這里面最重要的就是OMG。公眾對UML的接受刺激了以模型為中心的開發(fā)，OMG提供了支持這種開發(fā)的一系列標(biāo)準(zhǔn)的框架MDA（Model-Driven Architecture）。MDA的關(guān)鍵特點就是軟件開發(fā)的重點和輸出不再是程序，而是各種模型，開發(fā)人員的工作是不斷拓展模型，只有到了最后階段才會考慮將其實現(xiàn)。

OMG認(rèn)為，利用MDA可以得到更好的“高層抽象”設(shè)計框架，更好地得到針對今天各種語言的“通用化”代碼。和正在醞釀之中的基于XMI的數(shù)據(jù)交換一樣，基于MDA的數(shù)據(jù)交換方法將給開發(fā)商和用戶雙方帶來好處。

XMI（XML Metadata Interchange）試圖通過XML語言為程序員和其它用戶提供一種交換元數(shù)據(jù)信息的標(biāo)準(zhǔn)途徑。XMI希望能夠幫助使用各種語言和開發(fā)工具的UML開發(fā)人員zi you地交換數(shù)據(jù)模型，另外，XML也可以用于數(shù)據(jù)倉庫信息的交互；最重要的是，XMI制定了描述各種元數(shù)據(jù)定義的統(tǒng)一標(biāo)準(zhǔn)，并要求跨行業(yè)和跨操作環(huán)境的用戶使用一致的方法讀取數(shù)據(jù)。

今年6月，包含OMG MDA標(biāo)準(zhǔn)，促進模型交互的UML基礎(chǔ)庫修改版已經(jīng)正式提交討論。參與討論的包括用戶熟悉的很多開發(fā)商，包括I-Logix, Oracle, Rational, Telelogic and Computer Associates等等。

UML2.0中還將包括對組件建模的改進。近幾年來，隨著J2EE和微軟的.NET技術(shù)的出現(xiàn)，組件技術(shù)得到很大發(fā)展。這方面，UML2.0中將考慮如下內(nèi)容：如何更好地描述組件描述的語意以及構(gòu)建.NET和企業(yè)JavaBeans的專門模塊。

Jim Duggan ，artner公司的副總裁和研發(fā)總監(jiān)，認(rèn)為UML2.0中要處理的首要問題就是保證標(biāo)準(zhǔn)的擴展性，他認(rèn)為現(xiàn)行的標(biāo)準(zhǔn)中擴展機制定義得不夠，導(dǎo)致各開發(fā)商使用了不同的擴展方法。另外，還必須提供對組件開發(fā)、面向服務(wù)的框架以及web services的支持。

有人提倡，UML的發(fā)展應(yīng)該是向下兼容的，要保證過去基于UML1.x的用戶和工具開發(fā)商所做的努力不會全部作廢。UML2.0中應(yīng)該提高精確度，可以選擇加入少量的一些新特性，要避免導(dǎo)致“語言膨脹”的困境。而現(xiàn)在有一個不妙的苗頭： UML將變得越來越大，而在最初，OMG聲稱的目標(biāo)本來是簡單化的。

Gartner公司的Duggan認(rèn)為，“新的規(guī)約正在變得越來越復(fù)雜，變得非常大，難以管理、理解和實施。標(biāo)準(zhǔn)委員會曾經(jīng)說過將要把物理模型和邏輯模型分開。但是，一旦規(guī)約復(fù)雜化了，要做到這一點就不大可能，而且規(guī)約本身也開始失去作用。”

Alistair Cockburn，Humans and Technology的顧問，在他的論文中表達了同樣的意思。“在軟件開發(fā)中把人也當(dāng)成了非線性的、第一位的組件”，Cockburn認(rèn)為那些重量級的開發(fā)方法中試圖為一切建模，這是導(dǎo)致成功率不高的重要原因。他認(rèn)為在軟件開發(fā)中人是最重要的，在設(shè)計符號中把人當(dāng)成一個組件，就是最大的失敗之源。

其它公司，如Telelogic也在致力于利用UML2.0從圖形化的用戶模型中自動生成代碼。Telelogic在新加坡和亞洲其它地區(qū)創(chuàng)建了開發(fā)中心，力圖提供幫助從概念模型轉(zhuǎn)化到組件的軟件。Scott Raskin（如圖），Telelogic公司亞太地區(qū)總裁，認(rèn)為亞洲是這方面增長最快的地區(qū)。“UML允許組織從計劃到嵌入式系統(tǒng)實現(xiàn)的全部生命周期實現(xiàn)自動化”但是，對于有些程序員而言，并不需要UML，他們完成的代碼中通常都很難找到相似的地方，對他們來說，模型是多余的。

Gartner公司的Dugguan警告說，“要記住，UML只是一種符號，并不是什么方法論”。但事實上，幾乎所有的面向?qū)ο蠓治雠c設(shè)計（OOAD）工具和業(yè)務(wù)模型都是使用的UML。Dugguan指出，根據(jù)Gartner公司的估計，在所有項目中，使用OO A&D方法論的大概有10%到12%，和過去使用CASE工具的峰值數(shù)值幾乎相同。Dugguan認(rèn)為這個數(shù)字還會繼續(xù)增加到15%到20%。在數(shù)據(jù)建模領(lǐng)域，IDEF符號還在廣泛使用，但UML也開始進入。

Dugguan認(rèn)為，設(shè)計工具的總體使用率還是很低，在項目中使用設(shè)計驅(qū)動開發(fā)方式的大概有10%，通常是那些對質(zhì)量和持久性要求很高的項目。而數(shù)據(jù)建模工具在項目中使用的比率大概是35%，大多數(shù)情況下都是由DBA使用。

盡管UML可以和白板一起使用，但它還是復(fù)雜了些。Gartner公司認(rèn)為有以下原因?qū)е铝薝ML的低使用率。首先，在小的短期項目和開發(fā)周期中根本不用設(shè)計，都是采取的快速開發(fā)和演進。Dugguan說，“根本不需要最佳實踐，能用的實踐就夠了。”第二個原因是大多數(shù)遺留的程序都是面向過程的，不需要UML或者什么工具。但他又加了一句：“新的事件驅(qū)動和對象驅(qū)動的程序開發(fā)技術(shù)可以從UML工具中受益，新的開發(fā)人員很多都學(xué)過這些符號，而且會用相關(guān)工具”。

事實上，UML正在將工具開發(fā)商們凝聚在一起，很多公司都參與了UML2.0的修改過程。除了Rational之外， Microsoft、Sun、IBM、Oracle、Borland、Telelogic等公司也都是UML協(xié)會的成員。

（2002/10，UMLChina摘自computerworld，袁峰 譯，僅供學(xué)習(xí)交流，不得轉(zhuǎn)載用于商業(yè)用途）