隨著軟件系統(tǒng)復(fù)雜程度的提高，對好的建模語言的需求也越來越迫切，面向?qū)ο蠼ＵZ言就是應(yīng)這樣的需求而生。其實早在20世紀(jì)70年代就陸續(xù)出現(xiàn)了面向?qū)ο蟮慕７椒ǎ?0年代末到90年代中期，各種建模方法如雨后春筍般從不到10種增加到50多種。但方法種類的膨脹，使用戶很難根據(jù)自身應(yīng)用的特點選擇合適的建模方法，極大地妨礙了用戶的使用和交流。
在如此眾多的方法流派的競爭中，UML（Unified Modeling Language，統(tǒng)一建模語言）舉起了統(tǒng)一的大旗。它融合了多種優(yōu)秀的面向?qū)ο蠼７椒ǎ约岸喾N得到認(rèn)可的軟件工程方法，消除了因方法林立且相互獨立帶來的種種不便。它通過統(tǒng)一的表示法，使不同知識背景的領(lǐng)域?qū)＜摇⑾到y(tǒng)分析和開發(fā)人員以及用戶可以方便地交流。
它的出現(xiàn)為面向?qū)ο蠼ＵZ言的歷史翻開了新的一頁，并受到工業(yè)界、學(xué)術(shù)界以及用戶的廣泛支持，成為面向?qū)ο蠹夹g(shù)領(lǐng)域占主導(dǎo)地位的建模語言。OMG（對象管理組織）采納它為標(biāo)準(zhǔn)建模語言,進(jìn)一步將它推向事實上的工業(yè)標(biāo)準(zhǔn)的地位，目前它正向ISO（國際標(biāo)準(zhǔn)化組織）提出標(biāo)準(zhǔn)化申請。
盡管目前我國計算機(jī)界對UML的推崇程度近乎崇拜，但我們應(yīng)該客觀地認(rèn)識到UML依然存在許多缺憾甚至是錯誤，需要進(jìn)一步完善。一個規(guī)范的標(biāo)準(zhǔn)化進(jìn)程總是很漫長，在對它的修訂過程中總會不斷發(fā)現(xiàn)新問題，發(fā)現(xiàn)問題、解決問題是個循環(huán)反復(fù)的過程，在這個過程中，人們不斷改進(jìn)和完善UML。本期專題將追隨UML標(biāo)準(zhǔn)化進(jìn)程的腳步，介紹它修訂過程中的每一個進(jìn)步和缺憾,從而使讀者較為客觀地了解到UML的現(xiàn)狀及未來發(fā)展。
UML的現(xiàn)狀及未來發(fā)展
UML是在多種面向?qū)ο蠼７椒ǖ幕A(chǔ)上發(fā)展起來的建模語言，主要用于軟件密集型系統(tǒng)的建模。它的演化，可以按其性質(zhì)劃分為以下幾個階段：最初的階段是專家的聯(lián)合行動，由三位OO（面向?qū)ο螅┓椒▽W(xué)家將他們各自的方法結(jié)合在一起，形成UML 0.9。第二階段是公司的聯(lián)合行動，由十幾家公司組成的"UML伙伴組織"將各自的意見加入UML，形成UML 1.0和1.1，并作為向OMG申請成為建模語言規(guī)范的提案。第三階段是在OMG控制下的修訂與改進(jìn)，OMG于1997年11月正式采納UML 1.1作為建模語言規(guī)范，然后成立任務(wù)組進(jìn)行不斷的修訂，并產(chǎn)生了UML 1.2、1.3和1.4版本，其中UML 1.3是較為重要的修訂版。目前正處于UML的重大修訂階段，目標(biāo)是推出UML 2.0，作為向ISO提交的標(biāo)準(zhǔn)提案。
在多種面向?qū)ο蠼７椒髋刹⒋婧拖嗷ジ偁幍木置嬷校琔ML樹起了統(tǒng)一的旗幟，使不同廠商開發(fā)的系統(tǒng)模型能夠基于共同的概念，使用相同的表示法，呈現(xiàn)彼此一致的模型風(fēng)格。而且它從多種方法中吸收了大量有用（或者對一部分用戶可能有用）的建模概念，使它的概念和表示法在規(guī)模上超過了以往任何一種方法，并且提供了允許用戶對語言做進(jìn)一步擴(kuò)展的機(jī)制。
UML在語法和語義的定義方面也做了大量的工作。以往各種關(guān)于面向?qū)ο蠓椒ǖ闹魍ǔＪ且员容^簡單的方式定義其建模概念，而以主要篇幅給出過程指導(dǎo)，論述如何運用這些概念來進(jìn)行開發(fā)。UML則以一種建模語言的姿態(tài)出現(xiàn)，使用語言學(xué)中的一些技術(shù)來定義。盡管真正從語言學(xué)的角度看它還有許多缺陷，但它在這方面所做的努力卻是以往的各種建模方法無法比擬的。
從UML的早期版本開始，便受到了計算機(jī)產(chǎn)業(yè)界的重視，OMG的采納和大公司的支持把它推上了實際上的工業(yè)標(biāo)準(zhǔn)的地位，使它擁有越來越多的用戶。它被廣泛地用于應(yīng)用領(lǐng)域和多種類型的系統(tǒng)建模，如管理信息系統(tǒng)、通信與控制系統(tǒng)、嵌入式實時系統(tǒng)、分布式系統(tǒng)、系統(tǒng)軟件等。近幾年還被運用于軟件再工程、質(zhì)量管理、過程管理、配置管理等方面。而且它的應(yīng)用不僅僅限于計算機(jī)軟件，還可用于非軟件系統(tǒng)，例如硬件設(shè)計、業(yè)務(wù)處理流程、企業(yè)或事業(yè)單位的結(jié)構(gòu)與行為建模。
不過UML在取得巨大成功的同時，也不斷地受到批評。來自工業(yè)界的批評主要是，它過于龐大和復(fù)雜，用戶很難全面、熟練地掌握它，大多數(shù)用戶實際上只使用它一少部分的概念；它的許多概念含義不清，使用戶感到困惑。來自學(xué)術(shù)界的批評則主要針對它在理論上的缺陷和錯誤，包括語言體系結(jié)構(gòu)、語法、語義等方面的問題。
目前國內(nèi)也有不少軟件企業(yè)在學(xué)習(xí)并嘗試使用UML。從總體上看，我國計算機(jī)界對UML的了解還相當(dāng)初步，但是對它的崇拜程度卻遠(yuǎn)遠(yuǎn)超過了西方發(fā)達(dá)國家。人們在學(xué)習(xí)和使用UML遇到和國外用戶相同的疑難和困惑時，卻不太敢懷疑UML有什么問題。所以國內(nèi)幾乎沒有批評的聲音，偶爾有一點，也會立即被捍衛(wèi)的聲音淹沒，即使對UML一些最明顯的缺點和錯誤也是如此。
相比之下，國際上對UML的討論和評價則要客觀得多。無論是Internet上的意見交流，或是每年一次的UML研討會，還是學(xué)術(shù)期刊上發(fā)表的文章，都是既肯定其成績，又指出其缺點和錯誤，并且以積極的態(tài)度提出建設(shè)性意見。在醞釀UML下一次的重大發(fā)布和籌劃UML 2.0作為ISO標(biāo)準(zhǔn)提案的最近兩年內(nèi)，圍繞UML的討論更為活躍和熱烈。
為了使我國計算機(jī)界對UML目前的狀況有較為客觀的了解，我們從大量的文獻(xiàn)資料中選擇了三篇最具權(quán)威性的文章，介紹給我國讀者。從這組文章中，我們可以得到關(guān)于UML現(xiàn)狀及未來發(fā)展的重要信息：
● UML已經(jīng)取得重要成功，它已成為在軟件工業(yè)中占支配地位的建模語言，并在許多領(lǐng)域的軟件開發(fā)中得到應(yīng)用。
● UML還存在許多問題，自它產(chǎn)生之日起就從未離開過批評：用戶和教師抱怨它內(nèi)容龐大、難學(xué)難教而且太過復(fù)雜;學(xué)者認(rèn)為它缺少一個精練的核心和定義良好的外圍，有些語義定義得不夠精確而且?guī)в卸x性;建模實踐者認(rèn)為它缺少支持自己領(lǐng)域建模要求的機(jī)制;工具開發(fā)商則因為規(guī)范本身的不確定性而產(chǎn)生理解上的偏差，它們對UML的自行詮釋有可能誤導(dǎo)用戶。
● UML的關(guān)鍵問題是過于龐大和復(fù)雜，以及在語言體系結(jié)構(gòu)、語義等方面存在理論缺陷。產(chǎn)生這些問題的一個重要原因是，在形成規(guī)范的過程中不得不照顧多種方法流派的觀點和多家公司的利益。
● 為了UML的下一次重大發(fā)布，UML 2.0修訂的主持者正在廣泛收集各方面的意見。各界都給予了很高的關(guān)注，提出的意見涉及UML的各個方面。其中一個關(guān)鍵問題是UML是否需要簡化，以及如何使之更精練，最終大部分意見是提供一個精練的核心，而把不常用的內(nèi)容放到定義良好的外圍或擴(kuò)展機(jī)制中。此外，UML 2.0還將對UML的底層結(jié)構(gòu)、上層結(jié)構(gòu)和對象約束語言（OCL）做重大改進(jìn)。
原定UML 2.0在今年某個時間發(fā)布，但是在剛剛結(jié)束的本年度UML國際研討會上，沒有透露關(guān)于該版本最新進(jìn)度的任何消息，看來它的面世要比預(yù)期的日程推后。
UML 2001：標(biāo)準(zhǔn)化的《奧德賽》史詩
一個規(guī)范的標(biāo)準(zhǔn)化進(jìn)程通常是一個冗長的過程。在UML 1.3的最終草案被批準(zhǔn)之際，OMG UML修訂任務(wù)組和OMG分析設(shè)計平臺任務(wù)組聯(lián)合主席Cris Kobryn于1999年10月在《COMMUNICATION OF THE ACM》上發(fā)表了本文，總結(jié)了UML的發(fā)展歷程，并展望了其發(fā)展趨勢。
在很短的時間內(nèi)，UML已經(jīng)成為軟件工業(yè)中占支配地位的建模語言。目前它不僅是事實上的建模語言標(biāo)準(zhǔn)，也正在快速地成為法律上的標(biāo)準(zhǔn)。1997年，OMG采納它作為標(biāo)準(zhǔn)建模語言。現(xiàn)在，OMG正在以ISO公共可用規(guī)范提交者的身份，申請將UML規(guī)范作為國際標(biāo)準(zhǔn)。
不過，一個規(guī)范的標(biāo)準(zhǔn)化進(jìn)程通常是正式而漫長的，因為它要滿足各種各樣的技術(shù)規(guī)范和商業(yè)需求。從商業(yè)角度看，標(biāo)準(zhǔn)化的時間尺度通常與盡早使用最新技術(shù)的競爭需求是沖突的。從技術(shù)角度看，為了力求達(dá)成共識，則贊成這種"由委員會設(shè)計"的進(jìn)程。
標(biāo)準(zhǔn)化之前的歷史
早在1995年，Gray Booch和Janes Rumbaugh將他們的面向?qū)ο蠼７椒ńy(tǒng)一為Unified Method V0.8。一年之后Ivar Jacobson加入其中，共同將該方法統(tǒng)一為二義性較少的UML 0.9。同時，這三位杰出的方法學(xué)家被稱為"三友(Three Amigos)"。
很快用戶也認(rèn)識到可對軟件系統(tǒng)進(jìn)行可視化、描述、構(gòu)造和文檔化的通用建模語言所帶來的益處。他們充滿激情地將這種語言的早期草案應(yīng)用于不同的領(lǐng)域。受用戶強(qiáng)烈需求的驅(qū)動，建模工具廠商也很快在它們的產(chǎn)品中加入了對UML的支持。
與此同時，UML成了實際上的工業(yè)標(biāo)準(zhǔn)。1996年，一個由建模專家組成的國際性隊伍"UML伙伴組織"開始同"三友"一起工作，計劃將UML提議作為OMG的標(biāo)準(zhǔn)建模語言。
1997年1月，伙伴組織向OMG提交了最初的提案UML 1.0。經(jīng)過了九個月的緊張修訂，于1997年9月提出了最終提案UML 1.1，這個提案在1997年11月被OMG正式采納為對象建模標(biāo)準(zhǔn)。
有必要指出的是，由于比較倉促地通過了OMG的提交過程，盡管語言的基層結(jié)構(gòu)和大部分上層結(jié)構(gòu)是合理的，UML還是容忍了一些不盡如人意的負(fù)面因素：活動圖的語義及表示法不完整；標(biāo)準(zhǔn)元素臃腫，其中有些元素是為了滿足不同的、相互競爭的方法門派的需求而草率加入的，許多標(biāo)準(zhǔn)元素語義貧乏，而且命名和組織也不一致;結(jié)構(gòu)混亂，所提交的規(guī)范并沒有達(dá)到提交者預(yù)期的目標(biāo)--用一種嚴(yán)格的元模型方法實現(xiàn)4層元模型結(jié)構(gòu)，相反使用了一種實用但不精確的、松散的元模型方法，不利于UML同其他OMG規(guī)范的結(jié)合，比如與MOF（Meta Object Facility）的結(jié)合。
不過提交者們并沒有因此推遲UML的標(biāo)準(zhǔn)化進(jìn)程，而是在該語言的下一個修訂版中解決了上述一些問題。
發(fā)展進(jìn)程
OMG為修訂標(biāo)準(zhǔn)而提供的基本機(jī)制是提案需求（RFP，Request for Proposals）和修訂任務(wù)組（RTF，Revision Task Forces）。
其中RFP過程是OMG采納新規(guī)范和改進(jìn)已有規(guī)范的主要機(jī)制。任務(wù)組發(fā)布一個RFP，一個或多個提交團(tuán)以規(guī)范草案作為初始提案響應(yīng)該RFP，然后任務(wù)組對這些初始提案進(jìn)行評估，并反饋給提交者，鼓勵這些提交者與其競爭對手合作，從而形成最終提案。在任務(wù)組完成了對最終提案的評估后，就投票決定推薦眾多提案中的哪一個。獲得多數(shù)贊成票的提案就被送交組織委員會和主管該任務(wù)組的技術(shù)委員會去批準(zhǔn)。
如果一個最終提案獲得了所有的批準(zhǔn)，它就成為被OMG采納的技術(shù)。否則，任務(wù)組就有權(quán)重新發(fā)布一個修改過的RFP。
在一個規(guī)范被采納后不久，將成立一個修訂任務(wù)組，負(fù)責(zé)該規(guī)范的修訂。1997年9月，OMG采納UML 1.1規(guī)范之后不久，特許成立了第一個UML修訂任務(wù)組，負(fù)責(zé)收集有關(guān)評論，并且提出修改建議。
該RTF提交的第一個主要產(chǎn)品是一個編輯版本UML 1.2，它改編了規(guī)范，使之與其他OMG規(guī)范更為一致。盡管這一版本糾正了印刷和語法錯誤，以及某些明顯的邏輯上的不一致，但還是沒有涉及對重要技術(shù)的改進(jìn)。
該RTF的第二個主要的產(chǎn)品是其技術(shù)版本UML 1.3，它修正和改善了UML 1.1的遺留問題，并矯正了在此之后發(fā)現(xiàn)的許多小錯誤。該RTF一致推薦OMG批準(zhǔn)其UML 1.3最終草案，并于1999年6月提交了一份最終報告。被推薦的規(guī)范隨后被提交給組織委員會和平臺技術(shù)委員會以獲得批準(zhǔn)。
演變的體系結(jié)構(gòu)
UML是用元模型來描述的，元模型是4層元模型體系結(jié)構(gòu)模式中的一層。此模式的其他層次分別是：元-元模型層、模型層和用戶對象層。其中元模型層由元-元模型層導(dǎo)出，UML的元-元模型層在OMG MOF的元-元模型中定義，而UML元模型中的元類是MOF元-元類的實例。
元模型的體系結(jié)構(gòu)模式已被證明可以用來定義復(fù)雜模型所要求的精確語義，這種復(fù)雜模型通常需要被可靠地保存、共享、操作以及在工具之間進(jìn)行交換。它的特點如下：
● 它在每一層都遞歸地定義語義結(jié)構(gòu)，從而使語義更精確、更正規(guī)。
● 它可用來定義重量級和輕量級擴(kuò)展機(jī)制，如定義新的元類和構(gòu)造型。
● 它在體系結(jié)構(gòu)上將UML元模型與其他基于4層元模型體系結(jié)構(gòu)的標(biāo)準(zhǔn)（比如MOF和用于模型交換的XMI Facility）統(tǒng)一起來。
在元模型層，UML元模型又被分解為三個邏輯子包：基礎(chǔ)包、行為元素包和模型管理包。其中基礎(chǔ)包由核心、擴(kuò)展機(jī)制和數(shù)據(jù)類型三個子包構(gòu)成，它是描述模型靜態(tài)結(jié)構(gòu)的語言底層結(jié)構(gòu)，支持類圖、對象圖、構(gòu)件圖、部署圖等結(jié)構(gòu)圖。行為元素包是描述模型動態(tài)行為的語言上層結(jié)構(gòu)，支持不同的行為圖，包括Use Case（用況）圖、順序圖、協(xié)作圖、狀態(tài)圖和活動圖。模型管理包則定義了對模型元素進(jìn)行分組和管理的語義，它描述了幾種分組結(jié)構(gòu)，包括包、模型和子系統(tǒng)。行為元素包和模型管理包都依賴于基礎(chǔ)包。
UML 1.3的修訂
UML 1.3是建模語言規(guī)范第一個成熟的發(fā)布。它糾正或調(diào)整了從UML 1.1中繼承下來的遺留問題，并且修正了最終提交后的一年來所發(fā)現(xiàn)的大多數(shù)錯誤。從建模者的角度看，從UML 1.1到UML 1.3并沒有很大變化，對語言的大部分改進(jìn)是在底層對UML元模型語義的調(diào)整，只有很少量的變化是針對表示法的細(xì)枝末節(jié)的修改。底層結(jié)構(gòu)上的變化對大多數(shù)用戶來說是看不到的，但這使得UML在將來更容易實現(xiàn)和擴(kuò)展。
● 解決UML 1.1的遺留問題
完善活動圖的語義和表示法 增加了狀態(tài)的動態(tài)激發(fā)語義，定義了執(zhí)行條件線程的語義和表示法，而且增加了對象流功能。為了做這些修訂，還需要對活動圖所依賴的狀態(tài)機(jī)語義做以下修改:為同步并發(fā)的活動加入"同步狀態(tài)"、精化信號的語義、為合并狀態(tài)轉(zhuǎn)換定義附加的偽狀態(tài)。
清理關(guān)系的標(biāo)準(zhǔn)元素 引入關(guān)系元類來組織各種類型的關(guān)系，并且把依賴構(gòu)造型改造為依賴和流。此外，精練了泛化，不再需要以前的許多構(gòu)造型（如繼承、私有、子類、子類型等）。依賴和其他關(guān)系名稱的一致性也有所改進(jìn)。
體系結(jié)構(gòu)的一致性 通過加入物理元模型和XMI(XML metadata Interchange)DTD定義，提高了UML 1.3元模型的體系結(jié)構(gòu)跟MOF和XMI Facility的一致性。從UML語義邏輯元模型導(dǎo)出的物理元模型包含了一些支持產(chǎn)生IDL和XMI DTD的修改（例如將關(guān)聯(lián)類轉(zhuǎn)化為類）。盡管這樣做與嚴(yán)格的元模型方法相左，但它為未來UML的修訂達(dá)到這一目標(biāo)提供了橋梁。
● 其他變化
靜態(tài)結(jié)構(gòu)圖 放寬了限制，使類和接口之間可以關(guān)聯(lián)，并且在類中可以聲明信號。信號被定義為一個類元，可以操作。另外，還重新定義了模板和強(qiáng)類型的語義。
用況圖 用況之間的關(guān)系被重新定義為三種主要類型：泛化、包含和延伸。
交互圖 放寬了限制，使用戶可以描述角色或?qū)嵗６覅f(xié)作也可以泛化。
模型管理圖 改進(jìn)了模型和子系統(tǒng)的語義和表示法，將它們從包中分離出來，并使之更容易使用。澄清了對包的訪問和引入權(quán)限的區(qū)別。
盡管UML規(guī)范的核心是語法和語義定義，但它還包括模型交換、語言擴(kuò)展以及約束等方面的定義。UML 1.3對這些相關(guān)規(guī)范都進(jìn)行了錯誤糾正，并使之與核心語言的改進(jìn)保持一致。
為UML 2.0確立路標(biāo)
該RTF在最終報告中明確了因為超出其范圍或時間不允許而不能做的各種改進(jìn)。他們建議下一個RTF應(yīng)特別注意擴(kuò)展性和文檔管理方面的問題。對目前的擴(kuò)展機(jī)制，用戶和工具開發(fā)商已經(jīng)發(fā)現(xiàn)了一些重要問題，而涌入新UML外圍的提案可能會加劇這些困難。在文檔管理方面，物理元模型和XMI DTD規(guī)范的加入大幅度地增加了UML規(guī)范的長度，并使它變得笨拙難用（它現(xiàn)在已有800多頁了）。下一次UML修訂將會把物理建模規(guī)范拆分為單獨的文檔。
該RTF還進(jìn)一步建議負(fù)責(zé)起草UML 2.0 RFP的工作組考慮以下問題：
體系結(jié)構(gòu) 使用嚴(yán)格的元模型方法定義一個與MOF元-元模型嚴(yán)格一致的物理元模型。給出改進(jìn)的指導(dǎo)方針，以決定哪些部分應(yīng)該定義在核心語言中，哪些部分應(yīng)定義在UML的外圍或標(biāo)準(zhǔn)模型庫中。
擴(kuò)展性 提供同4層元模型體系結(jié)構(gòu)一致的擴(kuò)展機(jī)制。提高外圍規(guī)范的嚴(yán)密程度，使其支持用戶對語言定制能力不斷增加的要求。
構(gòu)件 增強(qiáng)基于構(gòu)件的軟件開發(fā)的語義和表示法。
關(guān)系 提供"精化"和"追蹤"依賴關(guān)系的基本語義。在多個抽象層次上定義關(guān)聯(lián)的語義。
狀態(tài)圖和活動圖 定義獨立于狀態(tài)圖語義的活動圖語義。在活動圖和狀態(tài)圖中提供更隨意的并發(fā)。詳細(xì)說明狀態(tài)機(jī)的泛化。
模型管理 重新定義模型和子系統(tǒng)的表示法和語義，以增強(qiáng)對企業(yè)體系結(jié)構(gòu)視圖的支持。
總體機(jī)制 定義一種模型版本管理的機(jī)制。詳細(xì)說明圖的互換機(jī)制。
體系結(jié)構(gòu)的十字路口：是雕刻還是糊泥巴？
在UML 1.3最終報告中就體系結(jié)構(gòu)問題強(qiáng)調(diào)指出：UML正在靠近OMG體系結(jié)構(gòu)的十字路口。OMG希望通過對體系結(jié)構(gòu)進(jìn)行改進(jìn)來完成技術(shù)上層結(jié)構(gòu)規(guī)范（例如應(yīng)用框架或商業(yè)構(gòu)件），以補充用于進(jìn)程間通信和分布式操作系統(tǒng)服務(wù)的CORBA底層結(jié)構(gòu)。雖然CORBA IDL對描述分布式計算底層結(jié)構(gòu)特別有效，它可以用來刻畫與界面關(guān)聯(lián)的操作，但卻不能用來定義方法、用況、協(xié)作、狀態(tài)機(jī)、工作流以及通常與實際商業(yè)構(gòu)件相關(guān)的各種關(guān)系。
因為UML允許用戶定義IDL所缺乏的語義，所以可以用UML來補充IDL。（用UML完全代替CORBA IDL對大多數(shù)OMG成員而言變化太劇烈。）然而在這種情況下，對那些想用關(guān)系和行為升級IDL結(jié)構(gòu)化規(guī)范的人而言，UML將面臨如下的挑戰(zhàn)：
學(xué)習(xí)的曲折性 UML是一種通用的建模語言，允許全面的語義表達(dá)。但盡管其基本的語言部分很容易掌握，更深層次的內(nèi)容卻需要足夠多的時間去學(xué)習(xí)。
語義臃腫 作為一種通用的建模語言，UML的復(fù)雜性和龐大是不可避免的，但其中也包含了大量詞義模糊、語義貧乏的標(biāo)準(zhǔn)元素。
輕量級的可擴(kuò)展性 UML目前僅提供輕量級的擴(kuò)展機(jī)制，如構(gòu)造型、約束和標(biāo)記。（相比之下元類是一種重量級的擴(kuò)展機(jī)制。）這些機(jī)制將受到一些簡單擴(kuò)展的挑戰(zhàn)，例如CORBA IDL接口的構(gòu)造型，還將受到來自對擴(kuò)展有更高需求的壓力，諸如應(yīng)用框架和分布式商業(yè)構(gòu)件。
元模型癖好 由于元模型現(xiàn)在被認(rèn)為是管理復(fù)雜的分布式體系結(jié)構(gòu)的強(qiáng)有力技術(shù)，許多建模者都渴望用這種新式的重磅大錘來解決本來用砸核桃的錘子（例如構(gòu)造型）甚至釘大頭針的錘子（例如標(biāo)準(zhǔn)模型庫中的一個類）就足以解決的問題。
這些挑戰(zhàn)要求OMG采用一種雕刻的方法（少即是多）而不是糊泥巴的方法來提煉和擴(kuò)展UML的體系結(jié)構(gòu)。尤其是OMG需要采取有效的三層結(jié)構(gòu)來決定哪些語言擴(kuò)展可以處理為對UML核心的修訂，哪些可以處理為獨立的外圍，而哪些可以處理為標(biāo)準(zhǔn)模型庫。如果這個三層結(jié)構(gòu)運行正常的話，核心部分將保持或提高其完整性，同時允許自然的選擇（借助OMG過程）來遴選最可行的外圍和標(biāo)準(zhǔn)化的模型庫。
定義UML核心
面對UML不斷增長的系統(tǒng)復(fù)雜性和更短的時間限制，新一代的建模者正在致力于消除，而不是增加這個已經(jīng)很龐大的軟件設(shè)計標(biāo)準(zhǔn)的復(fù)雜性。這是在2000年6月15日第二次國際年會上，《SOFTWARE DEVELOPMENT》技術(shù)編輯Roger Smith在主持完由工業(yè)界杰出人物組成的專門小組的圓桌討論之后得到的結(jié)論，并于會后將討論會的內(nèi)容組織成本文，發(fā)表在《SOFTWARE DEVELOPMENT》上。
在第二次UML國際年會上，《SOFTWARE DEVELOPMENT》技術(shù)編輯Roger Smith主持了在下列人士之間展開的圓桌討論，他們是:Cris Kobryn，OMG UML修訂任務(wù)組和OMG分析設(shè)計平臺任務(wù)組聯(lián)合主席；Martin Fowler，Melrose和Mass.-based ThouhgtWorks的首席科學(xué)家;Scott Ambler，Ronin國際軟件服務(wù)咨詢公司總裁；Peter Coad，Togethersoft公司的CEO。討論的焦點是UML的變革途徑，即UML的核心是什么，或者說應(yīng)該是什么，以及如何來擴(kuò)展它。
SD(software development):Kobryn，什么是UML核心？我們可以怎樣擴(kuò)展它？
Cris Kobryn：你可以將UML的核心看做實質(zhì)的UML，它可以用來對89%的普通問題建模。該核心可以在元模型層次上用元類或其他具有豐富語義的元實體（相對于具有貧乏語義的元實體而言）來定義。
任何優(yōu)秀的設(shè)計者的設(shè)想都是：下一代語言應(yīng)該從這種語言中精簡出來，而不是向其中添加。就是說，當(dāng)沒有東西可添加或者可刪除的時候，設(shè)計就做完了。
我們對2.0發(fā)布版承諾的關(guān)鍵部分是:一個精簡的核心，加強(qiáng)可定制性，以及改善對基于構(gòu)件的開發(fā)（比如EJB、CORBA和COM+）的支持。特別是2.0發(fā)布版將從體系結(jié)構(gòu)上精簡核心，并使之與其他關(guān)于元數(shù)據(jù)集成和儲存的OMG規(guī)范（例如元對象設(shè)施MOF）更加一致。
此外，對模型管理的支持將有所改進(jìn)，包括輔助分層、多視點和構(gòu)件框架。目前的共識是，模型版本管理不屬于新版UML的范圍。版本和圖的交換應(yīng)該由OMG的另一個結(jié)構(gòu)規(guī)范來處理，叫做XMI（即XML Metadata Interchange 格式規(guī)范，是一個通過Internet進(jìn)行對象數(shù)據(jù)交換的標(biāo)準(zhǔn)協(xié)議）。XMI不但可以用來交換模型語義，還可以用來交換模型圖。
開發(fā)商們對修訂會支持到什么程度？很顯然建模者希望UML易學(xué)易用，UML的復(fù)雜性使他們暈頭轉(zhuǎn)向，他們指出了很多UML的錯誤和使用中出現(xiàn)的問題，其中許多都超出了微小修訂的范圍。用戶因為缺少工具支持而經(jīng)常混淆工具帶來的局限和UML規(guī)范本身的局限，這使得他們很難明智地、準(zhǔn)確地批評UML。UML開發(fā)應(yīng)該是市場驅(qū)動的，如果用戶要求支持UML 1.3、1.4或2.0，開發(fā)商就應(yīng)該提供。
Scott Ambler:兩天前，我和這里的Norm Kerth和Neil Pitman在"UML世界"的一個為期一天的實習(xí)班上一起工作，這是我和Norm第三次在這種實習(xí)班上工作，有件事引起了我的注意。今年參與的每個人幾乎都做了同一件事：他們用了Use Case、順序圖和類圖。此后另一個組做了活動圖，但那是僅有的不同。而在1999年UML國際會議上，我和Norm教了同樣的實習(xí)班，使用同樣的筆記、同樣的講演，但是那些小組所用的方法要多得多，有些甚至超出了UML的界限。有人使用數(shù)據(jù)建模，還有人使用屏幕模仿。但是今年沒有人做屏幕模仿。這些人都是職業(yè)的軟件開發(fā)者，很有經(jīng)驗，也知道自己在做什么，但他們沒有想要超出UML的范圍。
Kobryn：Ambler，他們做了一些元模型嗎？
Ambler：沒有，那正是問題所在。哪怕他們只做了元模型建模，事情也就好辦了。學(xué)生們也反映到，他們需要一些方法、步驟或是一些關(guān)于如何使用UML的指導(dǎo)。客觀地說，UML并不是一種方法論或一種過程，但他們的意見恰恰顯示了他們贊成所有能真正符合現(xiàn)實世界發(fā)展的軟件過程。注意我沒有提到Rational統(tǒng)一過程（RUP）。
所以我打算持相反的觀點，并且要爭辯說UML還不夠復(fù)雜。根據(jù)我作為現(xiàn)實世界開發(fā)者的經(jīng)驗來看，UML并不充分。我經(jīng)常問：為了實際交付應(yīng)用軟件，我需要做什么？當(dāng)我問自己這個問題時，我很快發(fā)現(xiàn)UML遺漏了一些可以提供的東西，例如數(shù)據(jù)模型或用戶界面模型，為了交付軟件，我?guī)缀趺刻於家鲞@些東西。我需要理解用戶界面，而且要知道如何存儲數(shù)據(jù)。在UML中我沒有看到這些東西。或許Kobryn可以幫助在UML 2.0中注意這一點。
我們也學(xué)著對適當(dāng)?shù)墓ぷ鞑捎眠m當(dāng)?shù)墓ぞ撸@些工具可以是白板或紙。而有的時候，我喜歡選用豐滿的CASE工具，好的CASE工具可以簡化對UML的應(yīng)用，如果你精通它的使用方式的話。
SD：UML是否應(yīng)該考慮界面的設(shè)計或人類工程學(xué)因素？
Peter Coad：在我的印象中，Ambler在很多文獻(xiàn)和演講中提倡這樣的觀點:UML是一種建模語言，人們可能還要做其他一些事來勾勒出它的結(jié)構(gòu)，例如描繪用戶界面設(shè)計等。Jared Spool的《網(wǎng)站可用性：設(shè)計者指南》就是這方面的一部經(jīng)典著作，它將用戶界面設(shè)計和諸如類圖、交互圖、特征表之類的東西結(jié)合起來。但最終將在UML模型中放進(jìn)這些商業(yè)的東西和用戶界面嗎？這必須是UML的一部分嗎？我看不太合適，雖然這是好的工程實踐的一部分。
Ambler：我認(rèn)為UML應(yīng)該能夠描述窗口導(dǎo)航圖或用戶界面流圖。不管怎樣，我們在一些Web擴(kuò)展中看到了這些。如果能將它提取為用戶界面元素而不是Web用戶界面元素，那就更好了。說實在地，我很懷疑Web外圍的必要性。
Martin Fowler：我不同意這樣的觀點。如果不同的人用不相容的方法做相同的事，那應(yīng)該在把它放到UML之前去統(tǒng)一它。我并沒有看到在用戶界面設(shè)計方面已經(jīng)有這方面的嘗試。許多有趣的用戶界面設(shè)計思想正在浮現(xiàn)，但我不認(rèn)為已經(jīng)達(dá)到可以將其拉到標(biāo)準(zhǔn)中的程度。有些東西雖然重要，但并不意味著它必須進(jìn)入UML核心。
SD：Fowler，我確信你對此有獨到的觀點，因為你曾說過你全然沒有高估UML工具。你說過你可以用黑板和粉筆做正規(guī)的建模。但是否UML正變得太復(fù)雜而不適合那樣做呢？
Fowler：UML肯定需要簡化。不過因為各種技術(shù)和人為的因素，簡化工作并不是很容易。現(xiàn)在UML之所以會龐大到這種地步，正是因為一幫方法學(xué)家都將他們喜歡的技術(shù)加進(jìn)來。
而當(dāng)UML日漸成熟，并不是所有好的技術(shù)都要成為其中的一部分，UML的威力在于它允許人們做類似的事情并用通用的表示方法來表達(dá)。如果人們想做一些不同的東西，例如做Doug Rosenberg的健壯圖，我認(rèn)為不應(yīng)該把它們并入UML。
即使這樣UML還是有些龐大，Kobryn有一項困難的工作擺在面前，那就是要想方設(shè)法將核心縮減到最小。因此，我嘗試著提出一個核心。我在實踐中發(fā)現(xiàn)，有三種技術(shù)應(yīng)該包含在UML內(nèi)：Use Case、類圖和交互圖，剩下的可以進(jìn)入某種擴(kuò)展機(jī)制。這樣我將其中很多東西都去掉了，不過還有更多需要去除的東西，在Use Case中真正有用的部分是它的文本描述，而Use Case圖雖然使用起來很方便，但不是必需的，去掉Use Case圖的Use Case嚴(yán)謹(jǐn)而簡潔。
有很多符號是為特殊功用而設(shè)的，但哪些表示法能滿足大多數(shù)的需求？我想它們應(yīng)該是類、屬性、操作、關(guān)聯(lián)和泛化。我認(rèn)為不大應(yīng)該將交互圖去掉，順序圖也用得比較廣泛，或許可以去掉協(xié)作圖，因為目前對它的使用并不多，雖然我也覺得這樣有點激進(jìn)。最后就剩下Use Case的標(biāo)題、類圖和順序圖，足夠小了吧？
SD：但是Use Case圖很流行，有些人覺得Use Case圖是溝通管理者和最終用戶的最好方式,對他們來說該怎么辦呢？
Fowler：我不是說你只使用我提出的核心，你可以使用任何對你有幫助的技術(shù)。實際上，我甚至沒有說你應(yīng)該只用UML。但當(dāng)我考慮UML核心的時候，我得問，"什么是我能讓人輕松接受建模思想的最小數(shù)量？"在進(jìn)行實際建模時并不會只使用核心，我自己也不會。但那是我提議的最低限度。
SD：工具開發(fā)商們不應(yīng)該支持比最低限度更多的內(nèi)容嗎？
Fowler：每一個開發(fā)商都應(yīng)該支持核心和不同的UML擴(kuò)展片段。而購買者應(yīng)該能將它們分出層次，并且知道自己需要什么。
Kobryn：將核心與其擴(kuò)展部分分開并不像人們所想像的那么困難。UML元模型的結(jié)構(gòu)良好，雖然其中有缺陷，但要看怎么說。比如開發(fā)商完全或部分地遵守基礎(chǔ)語義、行為語義和狀態(tài)機(jī)了嗎？他們將語義和表示法分開了嗎？有很多這一類的問題，但開發(fā)商并不認(rèn)為自己應(yīng)該這么做，而用戶也沒有要求他們這么做。
Coad：為爭取更多的人使用UML，OMG可以提供預(yù)定義外圍的方式。而UML的用戶也應(yīng)該學(xué)會選擇自己想要的東西，即有較強(qiáng)的能力來定制他們的工具。
SD：我們?yōu)槭裁葱枰粋�UML核心？為什么不把實踐這個最重要的東西擺在首位，或者讓市場決定呢？
Kobryn:自然選擇是可以決定哪些在核心里面，哪些不在，但是我們必須首先處理那些語義貧乏的東西，我的意思是先清理語言本身然后再進(jìn)行自然選擇。此外，因為我們被卷到這個渾身長毛的東西的腸子里，所以一些清理工作必須從體系結(jié)構(gòu)上進(jìn)行，也要從用戶層次上來做。辦法就是通過圍繞一個核心的若干外圍來做這件事，就像Unix的內(nèi)核思想一樣。
SD：如果狀態(tài)圖、活動圖等元素不是核心的一部分，工具開發(fā)商們會不會找到一種方式，使用他們自己的外圍來代替這些元素？
Fowler：我想狀態(tài)圖等工具上的分歧不是問題，狀態(tài)圖作為核心的擴(kuò)展，是標(biāo)準(zhǔn)的一部分，如果你想支持狀態(tài)圖，你可以將它作為UML標(biāo)準(zhǔn)的一部分來開發(fā)。再強(qiáng)調(diào)一遍，核心不是整個的UML，重要的是選出一小部分。讓開發(fā)商來做互不兼容的東西，而當(dāng)不兼容成為問題時，UML的人就會站出來說："好，讓我們統(tǒng)一吧。"事實上，UML的崛起就是由于許多人做了一些相互矛盾的事情，而我們統(tǒng)一了它們。
Kobryn：我同意。UML中某些最豐富的語義與狀態(tài)圖和活動圖有關(guān)，我們當(dāng)然不會把孩子和洗澡水一起潑出去。狀態(tài)圖和活動圖可以放到外圍中，或者通過某種規(guī)則將其放到定義良好的元模型擴(kuò)展中。因此，讓我們明確一點:如果你想遵循Fowler和Coad建議的原則做一些簡單的事情，你可以把這些原則作為依據(jù)。但它的定義必須清晰，這樣當(dāng)用戶買一個工具的時候可以知道他得到了什么。
SD:各位愿意看到UML 2.0發(fā)布中有些什么呢？
Ambler:我對OMG加入更多的軟件工程方法提出異議。我們?yōu)槭裁床皇紫葘ξ覀冋務(wù)摰倪@些新的外圍設(shè)立需求呢？這是我對OMG的異議：首先是需求，然后才是設(shè)計。
Fowler:我不覺得UML目前需要很多修改。除了它以外還有很多更重要的東西：好的軟件設(shè)計原則、理解模式、對軟件過程的關(guān)注等。最主要的是UML能在一定程度上解決無聊的爭論，那時我們就可以轉(zhuǎn)移到更有趣的東西上。
Coad:我發(fā)現(xiàn)以小組的方式進(jìn)行工作能夠?qū)е聫?fù)雜性的瓦解。在17世紀(jì)，Blaise Pascal這樣寫道："我應(yīng)該寫更短的信，但我沒時間。"或許現(xiàn)在就是考慮更短書信格式的時候了，這對我們的工作會有所幫助。
Kobryn:如果有團(tuán)體的支持，核心的實現(xiàn)不是目前需要解決的主要問題。現(xiàn)在應(yīng)該注意需求，要在幾個月內(nèi)將需求文檔定稿，時間已經(jīng)相當(dāng)緊迫。它不是指令性的，也不能由任何一個開發(fā)商支配，我鼓勵每個人都去評論它。我希望已經(jīng)喚起了這樣的公眾意識：UML并不一定是你在自己喜歡的建模工具中所實踐的那樣，問一問你的開發(fā)商，至少搞清楚它們的產(chǎn)品是否遵守UML 1.1、1.3或其他版本。最后，我想鼓勵你直接參與，把你在RTF劃定的范圍內(nèi)不能建模的特殊問題發(fā)送給我，我會關(guān)注它們。
UML 2.0之路：快車道還是繞行？
UML已經(jīng)被迅速和廣泛地接受，但UML 1.X系列修訂版從來沒有離開過批評。在2000年6月國際年會的討論中，指出了它的很多缺點。這之后UML又經(jīng)歷了幾個里程碑，2000年9月，OMG發(fā)布了3個UML 2.0提案需求，詳述了對下一次重大修訂的RFP。今年2月，UML 1.4修訂任務(wù)組提交了UML 1.4規(guī)范的最終草案。對UML 2.0的重大修訂到底進(jìn)行得如何？Cris Kobryn于2001年4月在《SOFTWARE DEVELOPMENT》上發(fā)表了本文，分析了UML 1.4的改進(jìn)以及UML 2.0的修訂狀況。
最后的1.X系列
在歷經(jīng)17個月的討論和解決問題之后，第二個UML修訂任務(wù)組在今年2月結(jié)束了它的工作，并提交了一份名為《OMG UML V1.4:修訂和建議》的報告。
UML 1.4中最有意義變化的是對外圍和擴(kuò)展機(jī)制、構(gòu)件和制品以及協(xié)作和模式方面所做的改動。對外圍和擴(kuò)展機(jī)制結(jié)構(gòu)的修訂是為了使用戶和開發(fā)商能正確、有效地定制UML;修正構(gòu)件建模結(jié)構(gòu)是針對當(dāng)前基于構(gòu)件開發(fā)的需求;修正協(xié)作建模結(jié)構(gòu)則是為了改善語義組織并支持從屬協(xié)作。
對擴(kuò)展機(jī)制所做的改進(jìn)包括用圖形表示法和表格來描述構(gòu)造型和標(biāo)記值定義，對這些表示法的更新是為了支持大而復(fù)雜的外圍，比如與企業(yè)分布式對象計算和企業(yè)系統(tǒng)集成RFP的提議相關(guān)的那些外圍。圖1定義了一個構(gòu)造型《Persistent》，它可以用來詳細(xì)說明其實例能永久地存儲在數(shù)據(jù)庫中的類。《Persistent》基于UML元模型中的元類Class，包括三個用于Table、DB和isContainer的標(biāo)記定義（同性質(zhì)列表中的性質(zhì)相對比）。表1則顯示了同一個構(gòu)造型及其中一個標(biāo)記定義（Table）的表格形式。
提議對構(gòu)件的修訂則致力于允許建模者在軟件生命周期的早期階段詳細(xì)說明構(gòu)件，并且增強(qiáng)了對EJB和COM+的支持。在修訂的版本中可以更容易地區(qū)分可執(zhí)行構(gòu)件（如EJB Entity Bean、Com Objects等）和實現(xiàn)它們的制品（如EJB JAR文件、DLL等）。圖2顯示了一個構(gòu)件圖示例，其中包括構(gòu)件ShoppingCart、ShoppingSession和Catalog。有意思的是ShoppingCart還包括三個寄居在其中的類：ShoppingCart、ShoppingCartPK（"PK"表示主關(guān)鍵字）和ShoppingCartInfo。ShoppingCart類用關(guān)鍵詞《focus》標(biāo)記，表明它是類的構(gòu)造型《focus》的實例。同樣地，在ShoppingCartPK和ShoppingCartInfo上的關(guān)鍵字《auxiliary》表明它們都是構(gòu)造型《auxiliary》的實例，《auxiliary》也是類的構(gòu)造型。構(gòu)造型《focus》和《auxiliary》通常成對地使用，用以區(qū)別定義核心邏輯或控制流的類（例如中心類）和使用次要的邏輯或控制流的那些類（例如輔助類）。這些構(gòu)造型對定義類簇通常很有用，特別是在設(shè)計或分析階段。對構(gòu)件、模式和框架建模感興趣的讀者，可以參考構(gòu)件工作組的網(wǎng)頁（www.celigent.com/omg/umlrtf）。
UML 1.4的最終報告曾提到，由于UML 2.0 RFP的提交工作已經(jīng)開始，應(yīng)該考慮把UML 1.4作為UML 1.X系列最后的較小修改版。不過有一個例外，那就是集成UML RFP行為語義的最終提案，這一計劃將在完成UML 1.4之后提交UML 2.0初稿之前完成。
修正路標(biāo)
自去年舉行的UML WORLD 2000討論會以來，在UML的演化上最令人關(guān)注的發(fā)展之一，就是OMG決定將UML 2.0的工作劃分為幾個互補的、在系統(tǒng)體系結(jié)構(gòu)上密切合作的RFP：底層結(jié)構(gòu)RFP、上層結(jié)構(gòu)RFP和對象約束語言（OCL）RFP。將需求分類的好處在于使規(guī)范成果更加模塊化，并能同時進(jìn)行這些修訂。不過這也對維護(hù)體系結(jié)構(gòu)的完整性提出更大的挑戰(zhàn)，并且會導(dǎo)致更多的集成開銷。
1．UML 2.0底層結(jié)構(gòu)RFP
這個RFP致力于改進(jìn)UML體系結(jié)構(gòu)基礎(chǔ)，包括其核心和擴(kuò)展機(jī)制。其他的UML 2.0 RTP 將在此基礎(chǔ)上對上層結(jié)構(gòu)和相關(guān)的設(shè)施（例如圖形交互設(shè)施）進(jìn)行修訂。這個RFP的需求包括：在體系結(jié)構(gòu)上改進(jìn)與其他OMG建模規(guī)范的接口，例如MOF和XMI;重新構(gòu)造該語言，使其容易理解、實現(xiàn)和擴(kuò)展，當(dāng)然仍保留已被證實的語義和表示法結(jié)構(gòu);提供一級擴(kuò)展機(jī)制（特別是元類）以及與元模型體系結(jié)構(gòu)一致的外圍。
2．UML 2.0上層結(jié)構(gòu)RFP
該提案要求改善對軟件開發(fā)最優(yōu)方法的支持，例如基于構(gòu)件的開發(fā)、企業(yè)過程建模、體系結(jié)構(gòu)建模和可執(zhí)行的模型。它要求對很多體系結(jié)構(gòu)和行為建模構(gòu)造進(jìn)行修訂，特別是在以下領(lǐng)域：
● 改進(jìn)對基于構(gòu)件開發(fā)的支持，包括構(gòu)件裝配和運行時替換，能詳細(xì)描述用于主流構(gòu)件體系結(jié)構(gòu)（例如：EJB和COM+）的執(zhí)行容器和外圍。
● 增強(qiáng)對運行體系結(jié)構(gòu)的支持（與可執(zhí)行模型相比），包括對層次結(jié)構(gòu)和動態(tài)行為的規(guī)范。
● 精化關(guān)系語義，包括泛化、關(guān)聯(lián)和依賴關(guān)系。
● 改進(jìn)對行為建模的封裝和度量，特別是狀態(tài)圖和交互圖。
● 精化與事件管理以及控制和對象流規(guī)范相關(guān)的活動圖語義。
由于上層結(jié)構(gòu)RFP在相當(dāng)大程度上依賴底層結(jié)構(gòu)RFP，計劃底層結(jié)構(gòu)RFP在上層結(jié)構(gòu)RFP之前完成。
3．UML 2.0對象約束語言RFP
本RFP主要關(guān)心與UML元模型密切聯(lián)系的OCL元模型的定義。增加了OCL實現(xiàn)的精確性和一致性，并且便于在UML工具中交換OCL約束。盡管底層結(jié)構(gòu)和上層結(jié)構(gòu)RFP都可能使用OCL描述它們的形式化規(guī)則，但它們并不依賴于OCL RFP。
就在本文的寫作階段，OMG又成立了第四個RFP：UML 2.0圖交換RFP。其目的是在建模工具之間交互模型圖，也包括布局。（UML 1.4模型交換規(guī)范是UML 1.4的一部分，但它只描述了語義而沒有圖交換。）
是快車道還是繞行？
雖然UML 1.X系列的發(fā)展勢頭漸減，UML 2.0正在崛起，但現(xiàn)在預(yù)測UML 2.0的提交過程是否會進(jìn)展迅速還為時過早。標(biāo)準(zhǔn)化的過程是正式而漫長的，它需要尋求不同范圍的技術(shù)和商業(yè)需求的融合，沒有理由認(rèn)為UML 2.0的提交過程將是一個例外。除了前面已經(jīng)提到的關(guān)于集成多個RFP的問題之外，提交者還會遇到很多其他的挑戰(zhàn)，其中包括：
● 在體系結(jié)構(gòu)上與其他的OMG元模型體系結(jié)構(gòu)的協(xié)作性 像UML一樣，MOF和XMI也在不斷改進(jìn)，因此應(yīng)該注意修訂周期中的協(xié)調(diào)問題。
● 與元模型相對的外圍 在UML 2.0中，一級擴(kuò)展機(jī)制（在用戶層次上的元類）的引入，將進(jìn)一步檢驗用于描述平臺和領(lǐng)域定制語言的方法，這些方法多種多樣，而且都很具競爭力。
● 體系結(jié)構(gòu)建模 盡管都認(rèn)為體系結(jié)構(gòu)是個很好的概念，應(yīng)該在這方面多做些工作，但對于它是什么以及應(yīng)該怎樣描述它，在工業(yè)上達(dá)成的一致意見并不多。
● 行為語義的集成性 沒有明確將最終提交版與UML RFP的行為語義集成需要做多少工作。
● 在體系結(jié)構(gòu)上與其他規(guī)范的結(jié)合 例如與SDL－2000和EXPRESS的結(jié)合。應(yīng)從其他規(guī)范中借用有用的概念，并在技術(shù)上進(jìn)行綜合。
盡管面臨很大挑戰(zhàn)，但到目前為止，至少在體系結(jié)構(gòu)上已經(jīng)證明OMG在UML 1.X上的道路是可行的，沒有理由懷疑它會在UML 2.X系列中為我們提供有效的指引。
