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