邵偉中梅紅
最近，由美國Rational公司發起，其他十幾家公司聯合推出的統壹建模語言(UML)在OO領域引起了廣泛關註。本文首先介紹了UML的背景和主要內容，然後評述了它對面向對象建模技術的積極影響和可能存在的問題。UML是壹種強大的建模語言，具有豐富的表達能力。但目前還不能斷定它會取代現有的各種面向對象的分析和設計方法，因為它只是壹種建模語言，而不是方法；它的復雜性可能會成為它贏得大量用戶的障礙。
面向對象，建模方法，建模語言
中國圖書館分類號TP311
統壹建模語言綜述
邵偉中和洪梅
(計算機科學與工程系；技術，北京大學，北京100871)
由Rational軟件公司和其他UML合作夥伴發布的統壹建模語言(UML)在對象技術領域引起了廣泛的關註。介紹了UML的歷史背景和主要內容，討論了它的意義、積極影響和可能存在的問題。UML是壹種表達能力強、功能強大的建模語言；然而，不能斷定它會取代所有現有的面向對象的分析和設計方法。原因是UML只是壹個建模的顧嵐時代，而不是壹種方法，其過度的復雜性可能會成為贏得大量用戶的障礙。
關鍵詞面向對象，建模方法，建模語言
1 UML的背景
由於OOA/OOD方法的重要性日益突出，人們對其研究、開發和應用的熱情也日益高漲。1989年，以專著、論文或技術報告形式出現的OOA/OOD方法或OO建模語言近10種，到194年，OOA方法的數量已經增加到50多種。各種方法的出現或多或少為OOA/OOD技術的研究和發展做出了新的貢獻。這種蓬勃發展的局面表明，面向對象的方法和技術已經得到了廣泛的認可，並成為目前的主流。然而，各種方法的同時流行也帶來了壹些問題:各種OOA和OOD方法所采用的概念有許多相似之處，也有壹些不同之處(例如，許多方法在同壹部分)，在表示符號、OOA模型和文檔組織方面的差異就更加明顯，這往往使得壹些新用戶在選擇建模方法和工具時難以做出決策，也不利於他們之間的技術交流。
針對這種情況，1994年在美國Rational軟件公司工作的G.Booch和J.Rumbaugh認為應該把他們各自的方法(Booch方法[1]和OMT [2])結合起來，形成壹個統壹的方法。他們在那年六月開始這項工作。並且在1995，10公開發布了第壹個版本，也就是統壹方法0.8.1995秋OOSE的發起人I . Jacobson[3]加入了Rational軟件公司，也因此加入了這個行列。G.Booch、J.Rumbaugh和I.Jacobson。提出統壹建模語言的原因有三:No.1，各自的方法在進化中得到了結合；第二，走向統壹會帶來市場利益；第三，有助於改進各自的方法，從而獲得更多的學習者，解決過去各自的方法不能很好解決的壹些問題。
為了確定壹組用於分析和設計的符號，他們遇到了壹些需要權衡的問題。第壹，問題範圍的界定。比如說；需求規格應該包括在內嗎？(答案是肯定的，應該是部分收錄)；是否應該包含可視化編程語言？(答案是“沒有”)。第二，需要在表達能力和簡潔之間做出妥協。太簡單的表示會限制解決問題的能力，太復雜會讓普通開發者無所適從。第三，他們必須在他們原來的三種方法的基礎上進行組合，這也使他們擔心對原來方法的改變的大小。太大的改變會造成老用戶的困惑，如果保留原有的東西，就會失去做出改進和贏得更多新用戶的機會。根據UML文獻中提到的這些問題，UML的提出並不是簡單地從學術和技術的立場上尋找最合理的解決方案，而是必須考慮到壹些與公司、老用戶和原有方法相關的實際背景。
無論如何，他們在這種背景下做了他們認為最好的權衡，分別在10的6月和6月發布了UML版本0.9和0.91。從此，“統壹方法”被更名為“統壹建模語言”，因為它並不完全是壹種面向對象的建模方法。這是壹種面向對象的建模語言。它只是給出了壹組用於建模的元素和符號，並定義了它們的語義，而不是告訴如何對系統建模。正如M.Fowler在他關於UML的書[4]中指出的，“UML被稱為建模語言，而不是方法。至少原則上，大多數方法都是由壹個建模語言和壹個過程* * *。建模語言就是其中之壹。該流程是對設計中應采取哪些步驟的建議。”M.Fowler的這本書是以UML1.0為背景編寫的，G.Booch、I.Jacobson和J.Rumbaugh親自為書作序。這至少可以說明書中對UML的這種總體評價是得到其創始人認可的。
1996年，Rational準備向對象管理小組(OMG)申請使用UML作為標準建模語言。於是成立了UML的合作夥伴組織，包括Rational本身* * *和12家公司加入進來。他們推出了UML1.0版本。在1997中，作為初步提案申請提交給OMG。1997中，其他幾家公司分別向OMG提交了自己的建模語言提案申請。因此，UML夥伴組織將這些公司吸收到他們的行列中。為了反映這些新成員的意見，對UML1.0進行了修訂。Uml 1.1產生於1997年9月1並提交給OMG，OMG在同年采用了它。目前UML1.1是最新版本，但不是最終版本。因為還在修改中。截至UML1.1的發布，以下17家公司參與了UML聯合行動:Rational Software，Microsoft，Hewlett-Packard，Oracle，Sterling Software，MCI Systemhouse，Unisys，ICON Computing，IntelliCorp，i-Logix，IBM，ObjectTime，Platinum Technology，Ptech，Taskon，Reich Technologies和Softeam。
2 UML內容概述
根據UML文檔，“統壹建模語言(UML)是軟件系統產品規格說明的可視化構造和文檔化語言，也可用於業務建模和其他非軟件系統。”UML1.1提供了六個文檔，都是以UML夥伴組織中17公司的名義聯合發布的。本節先簡要介紹這些文檔，下壹節再介紹。
(1) UML概要:是對UML的壹般性介紹，包括它的動機、目標、範圍、歷史和現狀。
(2) UML語義:定義了UML的語義。該定義采用了形式化技術，但不是完全形式化的規範。語法結構被精確地描述，其動態語義用自然語言描述。UML的語法是與符號無關的抽象語法，它可以映射到不同的符號系統。雖然不是完全形式化的，但是，它的定義相當復雜:采用了四級元模型架構，文本長度達到160頁以上。在本文件的第2.2節中，介紹了模型的四個級別，即:
元模型:元模型的基本架構，定義了描述元模型的語言。
元模型:元-元模型的壹個例子，它定義了壹種描述模型的語言。
模型:元模型的壹個例子，它定義了壹種描述信息領域的語言。
④用戶對象:模型的壹個實例，定義了壹個特定的信息域。
各級模型元素的定義如下:首先給出其抽象語法(使用UML類圖表示描述元素之間的關系)，然後給出其形式化規則(使用文本和對象約束語言)，最後描述其語義(使用精確文本)。這樣壹共定義了118個元素，分為3個部分，9個包。
(3) UML符號指南:該文檔給出了UML的可視化表示，並通過實例給出了模型元素的圖形化表示符號。詳情見下壹節。
(4)對象約束語言規範(Object Constraint Language Specification):本文檔定義並介紹了壹種對象約束語言(Object Constraint Language，OCL)，用於解釋壹些在圖形系統模型中無法完全表達的建模信息。它是壹種正式的語言，但是很容易寫和讀。作為建模語言，並不意味著實現問題。換句話說，它是用來詳細解釋模型的，而不是用來編譯模型的。
(5)軟件工程目標過程的UML擴展:根據軟件工程的需求，定義了壹些UML擴展概念。例如，模型分為四種類型:用例模型、分析模型、設計模型和實現模型。給出了每個擴展模型概念的定義。它沒有介紹面向對象的開發過程，也沒有談到如何在過程中使用UML。文件內容很短，只有5頁。
(6)業務建模的UML擴展:定義了壹些業務建模的UML擴展概念，與前面的文檔類似，只是它的擴展是針對壹般的業務處理建模，而不是軟件工程。文件也很短。
3 UML符號指南
本文檔給出了UML的可視化表示，並通過實例給出了模型元素的圖形化表示符號。從系統模型的層次來看，UML表示由九種圖組成，它們是:
靜態結構圖，包括類圖和對象圖；
用例圖；
序列圖；
協作圖；
狀態圖圖表；
活動圖；
實現圖，包括組件圖和部署圖。
雖然UML文檔中說“UML符號指南定義了符號並提供了實例”，但確切的說法應該是:文檔給出了建模元素符號的壹般描述，其圖形的繪制用實例表示，沒有給出壹般的圖。本文中的大部分插圖都是參照M.Fowler的書[4]的做法，在壹般意義上給出的。
UML定義了各種圖中壹些常用的元素，如字符串(名稱)、標簽(標號)、關鍵字(關鍵字)、表達式(表達式)、註釋(註釋欄)等。，並給出了它們的表示符號。例如，關鍵字由包含在書名中的字符串表示。註釋欄由壹個角折疊的矩形中的文本表示。在各種圖中，用來封裝壹組模型元素的元素稱為“包”，用壹個大方框把這組元素圍起來，用角上的小方框給出包的名稱來表示。
此外，UML還定義了壹些稱為“擴展機制”的元素。這些元素可以附加到其他模型元素上，將原來的建模元素特殊化為具有特殊語義的新變體，或者表達它們的壹些細節。這些元素可以起到擴展或細化表示的作用。它們是:
約束:約束是模型元素之間的語義關系，解釋了某種條件和壹些必須保持為真的命題。它的表示就是在大括號之間用工具(比如UML提供的OCL)可以識別的語言寫壹個表示條件的文本字符串。
註釋:註釋是寫在註釋欄的符號(壹個角折疊的矩形)中的文本字符串。使用的語言應該是人們容易理解的，不管是否被工具理解。
元素屬性:用於顯示模型元素的壹些附帶特性，如屬性、關聯、目標值等。它的表現形式是用大括號把文本字符串寫成keywords = values的形式，多個字符串之間用逗號隔開。
原型(Stereotype ):用於附加到其他模型元素上，將原始模型元素專門化為具有特殊語義的新變體。帶有布局的模型元素可以看作是原始模型元素的壹個子類，在屬性和關系上與原始元素具有相同的形式，但在使用上更加具體。圖版類型由書籍名稱中包含的關鍵字表示。上述概念的表示如圖1所示。
圖1圖元素、包和擴展機制
下面分別介紹各種圖以及圖中使用的建模元素和表示。
(1)靜態結構圖
靜態結構圖包括類圖和對象圖。"類圖是靜態結構模型的圖形表示.""類圖是(靜態)聲明的模型元素的集合."關於對象圖，文檔中說:“對象圖是壹個實例的圖，包括對象和數據的值，靜態對象圖是類圖的壹個例子。它顯示了系統在某個時間點的詳細狀態的快照”。文檔還指出“對象圖的用處非常有限”，“工具不需要支持獨立的對象圖”。類圖可以包含對象，壹個包含對象但沒有類的類圖是壹個“對象圖”。然而，這壹術語仍然有助於描述可能以各種方式實現的特殊用法”。靜態結構圖中使用的各種建模元素的表示如下圖所示。
圖2靜態結構圖中建模元素的表示
類:類是壹組具有相似結構、行為和關系的對象的描述。UML為壹個類提供了三種圖形表示。1是壹種隱藏細節的方法，在壹個框中只給出類名。第二種方法是分析級詳細方法，在上、中、下三列分別給出類名、屬性名和類型、操作名；第三種是實現級細節方法，給出了更多的細節。
名稱區間:定義類符號名稱列的書寫規範。
列表區:定義類符號的屬性列和操作列的編寫規範。
Attribute:指定attribute和後面三個可見性符號的書寫方法:“+”表示公共，“#”表示受保護，“-”表示私有。
操作:指定操作的書寫方式，采用三個與屬性相同的可見性符號。
類型與實現類:這是兩個特殊的類元素，通過在類符號上附加布局關鍵字“類型”或“實現類”，並在屬性列和操作列中給出屬性和操作的定義細節而獲得。其中，“類型”描述了壹個對象可能采用然後拋棄的可變規則；“實現類”定義了壹個對象在語言中實現時的物理數據結構和過程。以下七個符號都是這樣得到的。
接口:接口是對類或其他實體(如包)的外部可見操作的描述。它沒有描述實體的結構。它的表示類似於類符號，但是沒有屬性列。在名稱列中添加關鍵字“接口”，在操作列中填寫接口定義。
參數化類(Template):它是壹個具有壹個或多個未綁定形參的類，所以它定義了壹個類族，並將形參與壹個實際值綁定，以解釋其中壹個類。參數化類的表示就是在類符號的右上角加壹個虛線框，在這個框裏解釋了每個形參的不同實現類型。
綁定元素:其功能是將模板的參數與實際值關聯(綁定)。它的表現就是用文字解釋模板的參數值表。
實用程序:以類的形式聲明的壹組全局變量和過程。它不是壹個基本結構，而是壹個編程工具。它的表示在類符號的類名列中用關鍵字“utility”標記。
元類:壹個類的類，它的例子是壹個類。其表現就是在類名列中添加關鍵字“元類”。
類路徑名:用於表示對類的引用。符號是在引用這個類的地方用符號“∷”表示被引用的類名(在其他包中)。
導入包:表示可以在壹個包中引用另壹個包中的類。這是壹種特殊的依賴關系。它的表現形式是將關鍵字“import”添加到依賴符號中(虛線箭頭)。
對象:對象是壹個類的特殊實例。UML給出的對象表示是壹個只有兩列的盒子。“名稱”列中填入了對象(實例)的名稱，並指明了它所屬的類名。每個屬性的值在屬性列中給出。
復合對象:由壹些緊密聯系的部分組成的高級對象，是復合類的壹個例子。它由壹個有兩列的方框表示。在上欄填寫復合對象的名稱並註明其類名，在下欄畫出其各個零件對象。
關聯:分為二元關聯和多元關聯，下面幾項分別介紹。
二元關聯:是兩個類之間的關聯(包括壹個類到自身的關聯的特例)。它的表現形式是用實線連接兩個類符號。這條線可以根據作圖方便畫成直線、斜線或曲線，也可以由幾段組成。線的端點與類符號相交的地方稱為關聯端點，在端點附近可以標註壹些有用的信息。指出關聯的不同情況(稍後描述)。整個關聯還可以攜帶壹些附加信息，包括:關聯名稱，表示關聯的作用；關聯類符號與普通類符號相同，但必須附加到壹個關聯中，以指示該關聯的屬性和操作。這些東西是可選的，不是強制性的。
AssociationEnd:關聯端不是壹個獨立的元素，而是關聯的壹部分，用來展現關聯的壹些細節。壹些細節是通過在聯想端旁邊附加壹些字符或圖形來表達的。包括多樣性、排序、限定符、角色名、可變性和可見性。其他細節用關聯線端點的不同形狀來表示，包括:空心箭頭表示可導航性，表示可以找到關聯壹端的對象實例。空心菱形箭頭表示聚合，表示關聯壹端的對象實例是另壹端的對象實例的組件；實心菱形箭頭表示壹種很強的聚集形式，稱為組合。
多重性:在關聯的端點上標記壹個數字(代表壹個特定的數字)或*號(代表多個)，以指示有多少個對象實例與另壹端的對象實例相關聯。
限定符，在關聯的壹端與類符號接口的地方畫壹個矩形框，並在框中給出壹些屬性值來表示關聯另壹端的對象滿足什麽條件才能與這壹端的對象關聯。它是協會的壹部分，而不是班級的壹部分。
關聯類用於表示壹個關聯具有類的特征(包括屬性和操作)，用普通的類符號表示，並附加在關聯線上。
n元關聯，三個以上的類之間的關聯，用從菱形到每個相關類符號畫連線來表示。
根據UML，組合是聚合的形式之壹，意味著整體與部分有很強的關系，並且具有相同的生存時間。它的表現是在關聯線的末端添加壹個實心菱形箭頭。
Link(鏈)是關聯的實例，表示兩個對象之間的聯系。它的表現就是在兩個對象實例之間畫壹條直線。
泛化:“是壹個更壹般的元素和壹個與之完全壹致的更特殊的元素之間的分類學關系，增加了更多的信息。”這個概念與大多數OO技術文檔中提到的“繼承關系”或“壹般特殊關系”基本相同，然而，UML的泛化不僅用於表示類之間的關系，還用於包、用例等元素。有兩種表達方式。壹種是* * *享受法，在壹般元素的符號旁邊畫壹個三角形，從三角形的底部畫壹條連線，這個連線有幾個分支，分別連接到每個特殊元素；另壹種是去中心化的，在壹般元素的符號旁邊畫多個三角形，每個三角形的底部畫壹條線通向壹個特殊元素。可以在該行旁邊添加壹個名為discriminator的文本標簽，以表明什麽是機密。
依賴:UML對依賴的語義定義如下:“指出兩個(或多個)模型元素之間的語義關系。它的含義只涉及這些元素本身，而不涉及它們的實例。它指出，對該依賴關系中的目標元素的更改可能需要對源元素進行更改。有以下幾種依賴關系:
痕跡-痕跡:在不同表意層次上代表同壹概念的兩個元素之間的歷史聯系。
細化-細化:兩個元素之間具有映射(不壹定完整)關系的歷史或派生連接。
用途-用法:壹個要素的正確實現或功能表現需要另壹個要素。
Bind-Binding:將模板參數綁定到實際值，以創建非參數元素。
依賴關系的表示是在兩個模型元素之間畫壹條帶箭頭的虛線，在依賴關系所屬的旁邊，或者加上壹個名字。《UML符號指南》在介紹依賴關系時並沒有談到它與消息概念的聯系和區別。“消息”和“消息流”等UML概念分別用於序列圖和協同繪圖(見後面)。然而，M.Fowler在參考文獻[4]中解釋道:“對於壹個類來說，依賴關系的存在可能是由於以下原因:壹個類向其他類發送消息；壹個類將其他類作為其數據的壹部分；壹個類引用其他類作為操作的參數。
派生元素:派生元素是可以從其他元素計算出來的元素。雖然沒有加入語義信息，但是可以更清晰或者更有利於設計。它的表現形式是在派生元素的名稱前加壹個斜杠“/”。
(2)用例圖
"用例圖用來表達參與者和用例之間的關系.""用例模型向系統外的交互者表達系統或類的功能."UML定義了組成用例圖的下列元素(如圖3所示)。
圖3用例圖
用例:用例是由系統或類提供的壹個緊湊的功能單元，它通過系統與壹個或多個外部交互者(即活動者)之間交換的消息序列以及系統執行的活動來體現。
參與者:參與者是由直接與系統交互的外部對象扮演的角色。
用例關系包括以下三種關系:通信，是活動者和用例之間唯壹的關系，是活動者對用例的參與；擴展，從用例A到用例B的擴展關系表明B的實例(在擴展描述的特殊條件下)可能包含A中描述的行為；用途:從A到B的使用關系表明A的實例也包括B中描述的行為.
(3)順序圖
UML給出了兩種形式的交互圖，壹種叫做序列圖，另壹種叫做協作圖。它們基於相同的基本信息，但強調不同的方面。序列圖顯示了按時間順序排列的交互。特別是，它顯示了對象在其生命線上參與的交互以及它們按時間順序交換的消息。它不顯示對象之間的關系。序列圖表示的交互是對象協作產生所需操作或結果時交換的壹組消息。序列圖有兩種繪制方式:簡單形式和詳細形式。後壹種畫法與OOSE [3]等著作介紹的交互圖基本壹致——橫向和縱向展示參與交互的物體。整個平面顯示了對象之間交互的時空關系，序列圖如圖4所示。用於序列圖的建模元素有:
圖4序列圖
對象生命線:顯示對象在從創建到撤銷的時間範圍內所扮演的角色的垂直虛線。
激活:顯示對象直接或通過其下屬流程執行活動的時間段。
消息:消息是對象之間的通信，用於傳遞信息和期望某種活動。消息的接收是壹個事件。
傳輸時間:發送或接收壹條消息所需的時間。兩者可以相同，也可以不同。
(4)協作圖
協作圖是UML提到的另壹種交互圖，它表示壹些對象之間組織的操作以及它們之間的鏈。與序列圖不同，協作圖表示的是對象角色之間的關系，而不是時間順序。協作圖描述了特定上下文中壹組相關對象之間的協作。以及當這組對象協作產生所需的操作或結果時交換的壹組消息。協作圖的圖形表示以對象為節點，既有表示消息的箭頭線，也有表示節點間關聯的連接線。消息線有三種，分別代表三種不同的消息，分別是調用、控制流和異步，但是還有壹些情況是無法表示的，比如balking和time out。需要壹些進壹步擴展的符號。協作圖中使用的相關符號還包括許多不同的端點情況，如限定符和組合等。協作圖如圖5所示。
圖5協作圖
UML符號指南為協作圖定義的概念或建模元素包括協作、協作內容、交互、模式結構、協作角色、多對象、活動對象、消息流和創建/銷毀標記，這裏不做介紹。
(5)狀態圖
狀態圖在UML中也稱為狀態機。它代表了壹個物體或壹個相互作用在整個壹生中受到刺激時的狀態序列，以及它的反應和活動。它被附加到壹個類或方法上。用於建立狀態圖的建模元素有:狀態(state)、復合狀態(compound state)、子狀態(Substate)、事件(Event)、簡單變遷(Simple Transition)、復雜變遷(Complex Transition)、嵌套狀態(Nested State)、發送消息(Sending Message)、內部變遷等。狀態圖及其相關元素的表示與大多數現有的OOA/OOD方法類似，在此不再贅述。
(6)活動圖
活動圖是狀態圖的變體。它的狀態指示操作執行的活動，它的轉換由操作的完成觸發。它表示流程本身的狀態機。進程是壹個類中操作的實現。構成活動圖的元素有:動作狀態、決策、泳道(泳道像遊泳池壹樣畫在圖中，每個活動組放在不同的泳道中，使之更清晰)、動作-對象流關系(活動-對象流關系，表示壹個活動與相關對象之間的消息和輸入/輸出關系)、控制圖標(表示信號的發送和接收)等。活動圖如圖6所示。
圖6活動圖
(7)實現圖
實現圖顯示了實現的問題，包括源代碼結構和運行時實現結構。實現圖有兩種，壹種是顯示代碼結構的組件圖，另壹種是顯示運行時系統結構的擴展圖。
組件圖顯示了源代碼、二進制代碼和可執行代碼等軟件組件之間的依賴關系。/ca & gt；