統一模組化語言(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系列中為我們提供有效的指引。