統一建模語言(UML)的現狀及發展

隨着軟件系統複雜程度的提高，對好的建模語言的需求也越來越迫切，面向對象建模語言就是應這樣的需求而生。其實早在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規範更爲一致。儘管這一版本糾正了印刷和語法錯誤，以及某些明顯的邏輯上的不一致，但還是沒有涉及對重要技術的改進。 http://www.mscto.com 該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在將來更容易實現和擴展。 http://www.mscto.com 　　● 解決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的異議：首先是需求，然後纔是設計。 http://w 　　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的修訂狀況。 http://www.mscto.com 　　最後的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;重新構造該語言，使其容易理解、實現和擴展，當然仍保留已被證實的語義和表示法結構;提供一級擴展機制（特別是元類）以及與元模型體系結構一致的外圍。 http://www.mscto.com 　　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系列中爲我們提供有效的指引。