UML術語大全
138.激發（fire）
激發一個轉換。見運行至完成（run to ,ompletion）、觸發(trigger)。
語義
當轉換要求的事件發生時，如果滿足監護條件，轉換將執行其活動，活動狀態改變。
對象接收到事件後，如果狀態機處於運行至完成這一步驟，則保存該事件。步驟完成後由狀態機處理這一事件。如果當前對象所處的狀態含有轉換，則相應轉換被觸發。如果是有多個源狀態的複雜轉換，則轉換進行前所有源狀態必須是活動的。源狀態活動完成後，可以執行完成轉換。如果源狀態爲組成狀態，所有直接子狀態完成或者達到終態後可以執行完成轉換。
處理事件後，計算監護條件（如果有的話）。如果條件的布爾表達式爲真，轉換將激發。激發轉換上的活動，轉換的目標狀態成爲活動的（內部轉換不改變狀態）。在狀態變化中，執行對象的原始狀態和轉換的目標狀態最短路徑上的任何出口活動和入口活動。注意，原始狀態可能是轉換源狀態的嵌套子狀態。
如果轉換不滿足監護條件，則不會激發。可能激發其他監護條件滿足的轉換。
如果有多個轉換可以激發，其中只有一個能真正激發。嵌套狀態內的轉換比外部轉換優先。否則轉換的選擇是不定的，這符合現實世界中的常見情況。
實際上，實現可以確定轉換激發的順序。這並不改變語義。合理設置監護條件以保證彼此互斥，可以達到相同的效果。更簡單的方法是採用"如果沒有進行其他轉換，則使用本轉換"。
延遲事件（Deferred events）
如果某個事件或其祖先在某個狀態中被定爲延遲的，則它將不觸發轉換，直到對象進入一個不要求當前事件延遲的狀態位置。對象進入新的狀態後，原來延遲而現在不延遲的事件成爲"pending (有待解決的)"，並以不確定的順序出現。如果第一個待解決事件沒有觸發轉換，則它將被忽略，下一個待解決事件出現。如果事件發生引起了狀態的轉換，則根據新狀態的延遲情況，重新確定尚處於待解決的延遲事件，建立新的待解決事件集。
實現可以更嚴格地規定延遲事件的處理順序，或者用某種操作來限制順序。
139.流(flow)
在不同連續時間點上同一個對象兩個版本之間的關係。
見成爲(become)、複製(copy)。
語義
流關係聯繫了同一對象在不同連續時間點的兩個版本。它可以連結實例級交互中一個對象的兩個值，或者描述符級交互中同一對象的兩個類元角色。它代表對象從一個狀態到另一個狀態的轉換，可以代表值、控制狀態、位置改變。
流依賴關係的構造類型有成爲（become）和複製(copy)，用戶可以增加其他構造類型。
表示法
流關係用帶有構造類型的虛線箭頭表示，構造類型不能省略。
標準元素
成爲、複製
140.控制焦點(focus of control)
順序圖中的一個符號，表示對象直接或者間接（通過子程序）執行一個活動的一段時間。
見激活（activation）。
141.字體使用(font usuage)
用不同字體或者其他圖形標誌來區分正文。
見圖形標誌(graphic marker)。
討論
斜體字表示抽象類、屬性、操作。其他字體用於強調或者區別表示語法中的不同部分。建議對於類元名字、關係名字用黑體字；對於內容，屬性、操作、角色名等用正常字體。分格的名字用特殊字體，選擇權在於編輯工具。工具可以選擇字體來強調元素、區分保留字、表示元素的特定屬性。也可以允許用戶選擇字體。對於顏色有類似的考慮，有色盲的人可以不用顏色區分。上述所有內容是對於本書所述表示法的擴展。
142.分叉（fork）
複雜轉換中，一個源狀態可以轉入多個目標狀態，使活動狀態的數目增加。
反義詞：結合。
見覆雜轉換(complex transition)、複合狀態(composite state)、結合(join)。
語義
分叉是指有一個源狀態和多個目標狀態的轉換。如果在源狀態活動時出現觸發事件，所有目標狀態將成爲活動的。目標狀態必須是並行組成狀態中的不同區域。
表示法
分叉表示爲有一個轉入箭頭和多個轉出箭頭的粗線，它可以帶有轉換標籤（監護條件、觸發事件和活動）。圖13-101是進入並行組成狀態的明顯分叉。
圖13-101 分叉
143.形式參數（formal argument）
見參數(parameter)
144.框架(framework)
爲某個域中的應用程序提供可擴展模板的泛化結構。
見包(package)。
145.友元
一種使用依賴關係，允許用戶訪問服務提供者。
見訪問(acess)、導入(import)、可視性(visibility)
語義
友元依賴關係用於保證一個操作或者一個類對使用類的內容的許可，雖然從另外角度看來許可不夠充分。它通常是規則中的異常，這種功能要小心使用。
表示法
從得到許可的類或者操作向提供內容的類引一條虛線表示友元依賴關係；構造類型關鍵字《friend》標在箭頭上。
146.完整描述符(full descreptor)
一個直接實例的完整隱含描述。一個完整描述符通過繼承其所有祖先組裝而成。
見直接類、繼承、多類元。
語義
實際上，對於類或者其他元素的聲明只是其實例的部分描述，稱爲類片斷（class segment）。通常類的對象含有比它的直接類所描述的更多的結構。對實例所有的屬性、操作和關聯的描述稱爲完整描述符，它通常不由模型或程序表示。繼承規則的目的就是提供一種自動將類片斷組成爲完整描述符的方法。理論上有不同的實現方式，稱爲元對象協定（metaobject protocol）。UML爲繼承定義的一系列規則，涵蓋了大多數程序設計語言，也可用於建立概念模型。注意，可能存在其他可能性，如CLOS語言等。
147.功能視圖(functional view)
這種視圖將系統分解爲功能或者提供功能的操作。通常認爲功能視圖不是面向對象的，可能導致不易維護的結構。傳統開發方法中，數據流圖是功能視圖的核心。UML不直接支持這種視圖，但是活動圖中有一些功能特性。
148.可泛化元素(generalizable element)
可以參與泛化關係的模型元素。
見 泛化(generalization)、繼承(inheritance)
語義
可泛化元素可以有父和子。被類元成帶有元素的變量可以帶有該元素後代的實例。
可泛化元素包括類、用例、其他類元、關聯、狀態和合作，它們繼承其祖先的特徵。每種可泛化元素的哪個部分是繼承來的，要看元素的種類。例如類繼承屬性、方法、操作、關聯中的地位和約束；關聯繼承參與類（本身可被特化）和關聯端的特性；用例繼承屬性、操作、與參與者的關聯、與其他用例的擴展和包含關係、行爲序列。狀態繼承轉換。
見泛化(generalization)、關聯泛化(association generalization)、用例泛化(use case generalization)。
結構
可泛化元素的屬性聲明它可以在泛化關係中的何處出現。
抽象 說明可泛化元素是描述直接實例的，還是抽象元素的。True表示元素是抽象的（不能有直接實例）；false表示它是是體（可以由直接實例）。抽象元素的實體後代才能使用。帶有無方法操作的類是抽象的。
葉 說明可泛化元素是否可以特化。True表示元素不能有後代（葉）；false表是可以有後代（無論當前是否有後代）。作爲葉的抽象類只能起組織全局屬性和操作的作用。
根 說明元素是否必須爲無祖先的根。True表示元素必須爲根；false表是不必爲根，可以有祖先（無論當前是否有祖先）。
注意：聲明葉或者根不影響語義，但這種聲明可以給設計者提示。如果能避免對全局變量的分析或者對多態操作的全局保護，就可以有更高的編譯效率。
標準元素
葉
149.泛化(generalization)
一個較廣泛化的元素和一個較特殊的元素之間的類元關係。特殊化的元素完整的包含了廣泛化的元素，並含有更多信息。特殊化的元素的實例可以用於任何使用廣泛化元素的地方。
見泛化關聯(association generalization)、繼承(inheritance)、可替換規則(substitutability principle)、用例泛化(case generalization)。
語義
泛化是兩個同類的可泛化元素之間的直接關係。其中一個元素被稱爲父，另一個爲子。對類而言，父稱爲超類（superclass）,子成爲子類。父所說明的直接實例帶有所有子的共同特點，子所說明的實例是上述實例的子集，不僅有父的特徵，還有獨有的特徵。
泛化是一種反對稱關係。按照一個方向轉變成爲父，另一個方向引向子。在父方向上經過一個或幾個泛化關係的元素稱爲祖先；在子方向上經過一個或幾個泛化關係的元素稱爲子。不允許出現泛化環，一個類不能既是自己的祖先又是自己的後代。
在最簡單的情況下，類（或者其他可泛化元素）有單一的父。在複雜情況下，子有多個父。子繼承了父的所有結構、行爲和約束，稱爲多重繼承（或者多重泛化）。父元素對子元素有可視性。
關聯、類元、狀態、事件和合作都可以泛化。
關於關聯的泛化的應用，見關聯泛化。
關於用例的泛化的應用，見用例泛化。
節點和構件類似於類，它們的泛化與類類似。
約束
約束可以應用於一列泛化關係，以及有同一個父的子。可以規定下列屬性：
互斥 一個祖先不能有兩個子（多重繼承時），實例不能同時成爲兩個子的間接實例（多重類元語義）
重疊 一個祖先可以有兩個或者更多的子，實例可以屬於兩個或者更多的子。
完整 列出了所有可能的子，不能再增加。
不完整 沒有列出所有可能的子，有些已知子沒有聲明，還可以增加新的子。
表示法
類元之間的泛化關係表示爲子元素（如子類）到父元素之間的實線路經，路徑指向更廣泛的元素的一端帶有空心的三角形（圖13-102）。指向父的線可以是組成或者樹（圖13-102）。
圖13-102 泛化關係
圖13-103 樹形泛化關係
泛化還可以應用於關聯，但是太多的線條可能使圖很亂。爲了標明泛化箭頭，可以將關聯表示爲關聯類。
如果圖中沒有標出模型中存在的類，應該在相應位置上用省略號（...）代替。（這不表示將來要加入新的類，而是說明當前已經有類存在。這種方發表示忽略的信息，而不是語義元素）。一個類的子類表示爲省略號說明當前至少有一個子類沒有在視圖中標處。省略號可以有描述符。這種表示法是由編輯工具自動維護的，不用手工輸入。
表示選項
到一個超類的一組泛化路徑可以被表示爲有一段公用路經（包括三角形）的樹，樹枝指向子類。這只是一種表示法，不代表n維關係。在當前模型中，每對超類--子類之間有一個泛化關係。弧分開來畫沒有語義上的區別。
如果在幾個子類公用的泛化三角形上帶有文本標籤，則標籤適用於所有路徑。換言之，是所有子類共享的屬性。
舉例
圖13-104是泛化關係上聲明的約束。圖中表示了"樹形"泛化（路徑爲平行線，有公用的箭頭）；同時表示了"二元形"泛化（每一對父--子關係有獨立的箭頭）。
圖13-104 泛化約束
定義泛化關係中的元素時不用瞭解這一元素，但是子元素必須知道父元素的結構。通常，父元素就是爲了供子元素擴展而設計的，因此設計時應瞭解預期的子元素。泛化關係的優點之一就在於經常可以出現設計父元素時沒有想到的子元素，這帶來了更強的功能。
實現關係與泛化關係類似，不過僅僅繼承了行爲說明。如果說明的元素沒有屬性、關聯，而只有抽象操作，則泛化和實現是相同的。實現關係不生成用戶，因此操作必須在用戶中，或者從其他元素處繼承來。
標準元素
完整，互斥，實現，不完整，重疊
150.圖形標記(graphic marker)
一種標記元素，如幾何圖形、紋理、填充模式、字體、顏色等。
見字體使用(font usage)
表示法
表示符號是由不同的圖形標記構成的。一個圖形標記本身沒有語義作用，但是表示法的目的就是儘可能多地組成使用圖形標記。
有些圖形標記用於構造預定義的UML符號，而其他不用於標準表示。顏色沒有被賦予含義，因爲有些打印機不支持彩色，有些人不能分辨色彩。這些未定義的圖形標記可以按照建模者或者工具的需求供編輯工具使用。
UML表示法只允許有限的圖形擴展。圖標或圖形標記（如紋理、顏色）可以與構造類型聯繫起來。UML沒有定義圖形說明的格式，但是有很多位圖和格式可供圖形編輯器使用（雖然其可移植性很難滿足）。
圖標說明及其替代表示的一般形式易於理解，我們也允許工具開發者溶入自己的想象--注意，擴展性的過度使用可能會造成工具可移植性的減弱。
151.監護條件(guard condition)
進行相關轉換之前必須滿足的一個條件。
見分支(branch)、條件線程(conditional thread)、結合狀態(junction state)、轉換(transition)
語義
監護條件是一個布爾表達式，它是轉換說明的一部分。收到轉換的觸發事件之後，系統保存該事件直到狀態機已經完成任何運行至完成步驟，隨後進行事件處理，計算監護條件。如果條件爲真，則可以進行轉換（如果有多個轉換可以進行，只能進行一個）。事件處理時進行測試。如果此時條件爲假，除非觸發事件再次出現，否則不再重新計算監護條件。
監護條件必須是一個詢問--它不能修改系統的值或者狀態的值，又不能有副作用。
完成轉換也可以有監護條件，此時，它選擇一個分支執行。
表示法
監護條件是轉換字符串的一部分，它是用方括號括住的布爾表達式
[布爾表達式]
表達式中用到的名字必須是轉換內部可見的，可以是觸發事件的參數或者當前對象的屬性。
152.書名號(guillemets)
（《》）在法語，意大利語和西班牙語中表示引用。在UML表示表示法中表示關鍵字和構造類型。許多字體中都有，必要時可以用兩個尖括號代替。（<< >>）。
見字體使用。
153.歷史狀態(history state)
一種僞狀態，說明當前的內部組成狀態記得它存在之後曾經有的活動子狀態。
見組成狀態、僞狀態、狀態機、轉換
語義
歷史狀態允許順序組成狀態記住從組成狀態發出的轉換之前組成狀態的最後一個活動子狀態。轉向歷史狀態的一個轉換將使前一個活動子狀態再次成爲活動的，並執行相應的入口活動和出口活動。歷史狀態可以有來自外部狀態或者初始狀態的轉換。可以有一個沒有標籤的向外轉換，該轉換表示原先保存的歷史狀態。當沒有保存的狀態時，轉向歷史狀態就會轉向它。歷史狀態不能有來自組成狀態內部的其他轉換。
歷史狀態可以記憶淺歷史和深歷史。淺歷史狀態保存並激活與歷史狀態在同一個嵌套層次上的狀態。如果一個轉換從嵌套子狀態直接退出組成狀態，將激活組成狀態中頂級的終止子狀態。深歷史狀態記憶組成狀態中更深的嵌套層次的狀態。要記憶深狀態，轉換必須直接從深狀態中轉出。如果一個轉換是從深狀態轉換到一個淺狀態，並由此轉出組成狀態，將被記憶的將是淺狀態的轉換。到一個新歷史狀態的轉換恢復任何層次上曾激活的狀態。在這個過程中，如果入口活動出現在包含所記住狀態的內層狀態上，則執行該入口活動。組成狀態可能同時有深淺兩種歷史狀態，進入的轉換必須連到二者之一。
如果組成狀態進入終態，則它將丟棄所有保存的歷史狀態，好像從沒進入過此狀態一樣。
表示法
淺歷史狀態用帶有H的小圓圈表示，如圖13-105所示。深歷史狀態是帶有H*的圓圈。
圖13-105 歷史狀態
154.超級鏈接(hyperlink)
兩個表示元素之間可以通過某些命令穿越的不可見連接。
見圖(diagram)。
表示法
紙面上的表示法不包含隱藏信息。但是計算機屏幕上的表示法可以帶有附加的不可見的超級鏈接，它們在靜態圖中不出現，但是在動態圖上可以被激活，從而訪問其他信息。這些信息或者在圖形視圖中或者在文字表中。這種動態鏈接如同可視信息一樣，是動態表示法的一部分。本文沒有限制它們的使用，只是我們沒把它們當成工具的必要功能。本文試圖爲UML定義一種靜態表示法，但是有些有用信息難以在這些視圖中表示。另一方面，我們對動態工具的瞭解不夠，又不想對創新的動態表示法隻字不提。最終，成熟的動態表示法將成爲標準，但是目前爲時尚早。
155.標識(identity)
一個對象的繼承屬性，用於將它區別於其他對象。
見數據值(data value)、對象(object)。
語義
對象彼此是不同的。一個對象的標識符是它的概念句柄，是一個供其他對象引用或確定的繼承特徵。概念上，對象不需要用主鍵(key)或其他機制來標定自身，這種機制不應該存在於模型中。在實現中，標識符由地址或者主鍵實現，但它們是基本實現結構的一部分，不用顯示地列爲大多數模型的屬性。
156.非良性結構(ill formed)
模型的結構設計不正確，其中有一個或多個預定義的規則或約束被違反。對比：結構良好。
見衝突(conflict)、限制(constraint)。
語義
違反良好結構規則和約束的模型是不能使用的，因爲其語義是矛盾的。使用這種模型將產生無意義的結果。建模工具有責任找出非良性結構並加以隱藏，防止出現更大的問題。因爲有時會使用UML內置語義之外的擴展結構，所以並不總能保證自動識別。此外，自動檢查不能保證操作的一致性。因此，在實踐中應該結合自動識別與人工識別。
完成的模型必須是結構良好的，但是模型建造的某個中間步驟生成的模型版本可能是非良性結構的，因爲那只是未完成的框架。將一個可用的模型修改爲新的模型的過程中，也可能生成非良性結構的模型。這類似於編寫程序--供編譯的程序必須是可用的，但是文本編輯區的中間版本可以是不能用的。因此，支持工具必須可以編輯和保存非良性結構的模型。
157.實現(implementation)
1． 定義某事物是如何構造、計算的。例如，類是類型的實現；方法是操作的實現。對比：說明。實現和說明之間是實現關係。
見關係(realization)
2． 用可執行的媒介（如程序設計語言、數據庫、數字化硬件）描述系統功能的一個步驟。對實現而言，必須產生下層的決策以使設計適合具體的實現媒介，並與環境相適應（每種語言有各自的限制）。如果設計得好，實現的決策將是局域性的，任何決策不會影響系統的全局。這一步由實現層模型捕捉，特別是靜態圖和代碼。對比：分析、設計、實現和配置。
見開發過程(development process)、建模步驟(stages of modeling)。
158.實現類(implementation class)
物理實現的類的構造類型，包括屬性、與其他類的關聯和操作的方法。一個實現類將用於具有靜態單類元的傳統面嚮對象語言。這樣，系統中的一個對象必須有且只有一個實現類作爲它的直接類。與類型不同，類的構造類型允許多個類元。在某些語言中（如JAVA），對象可以有一個實現類和多個類型，實現類要與類型一致。
見類型(type)，其中對比了類型和實現類。
159.實現繼承(implementation inheritance)
繼承父元素實現--繼承結構（如屬性和操作）與代碼（如方法）。相反接口繼承包括了對接口說明的繼承（操作），但是不繼承方法和數據（屬性和關聯）。
UML中泛化的意義包括接口和實現的繼承。如果僅僅繼承實現（私有繼承），可以在泛化關係上使用關鍵字《implementation》。如果只要繼承接口，可以使用到接口的實現關係。
見泛化(generalization)、繼承(inheritance)、接口繼承(interface inheritance)、私有繼承(private inheritance)。
160.實現視圖(implementation view)
模型的一種視圖，包含系統中構件的靜態聲明、依賴關係和可能由構件實現的類。
見構件圖(component diagram)。
161.導入(import)
許可依賴關係的一種構造類型，其中提供者包中的元素名字被加入用戶包的命名空間。
見訪問(acess)、包(package)、可視性(visibility)。
語義
提供者包的命名空間中的名字被加入用戶包的命名空間，訪問指定的可視性規則不變。如果導入的名字和原有命名空間的名字衝突，說明出現模型爲非良性結構。
見訪問(acess)，以及訪問和導入的可視性規則。
表示法
用虛線箭頭從得到訪問權限的包指向提供者所在的包，箭頭上帶有構造類型《import》。
162.不活動(inactive)
不活動的狀態，不能由任何對象處理。
163.初始(inception)
軟件開發過程的第一步，這期間設計計算系統的原始方案，開發某些分析視圖和少量其他視圖。
見開發過程(development process)。
164.包含(include)
基用例與包含用例之間的關係。說明如何將包含用例中定義的行爲插入基用例定義的行爲中。基用例可以看到包含用例，並依賴於包含用例的執行結果。但是二者不能訪問對方的屬性。
見擴展(extend)、用例(use case)、用例泛化(use case generalization)
語義
包含關係聯繫了基用例和包含用例。關係中的包含用例不是能夠獨立實現的類元，而是顯式說明插入執行基用例的用例實例中的附加行爲序列。一個基用例可以有多重包含關係。同一個包含用例可以被包含於多個基用例中，這些基用例之間不必有任何關係。只要每個插入在基用例的不同位置，同一對基用例和包含用例之間可以有多個包含關係。
包含用例可以訪問基用例的屬性或者操作。包含用例提供了可被多個基用例重用的特有行爲。基用例可以看到爲它設置屬性值的包含用例，但不能訪問包含用例的屬性，因爲當前基用例重新得到控制後，包含用例已經結束了。
注意：（所有種）附加內容可以嵌套。一個包含可以是各種進一步包含、擴展或泛化關係的基。
結構
包含關係有下列屬性：
位置 基用例的行爲序列體中的位置，在此位置處可以插入包含。當執行基用例實例達到該位置時，用例實例執行包含用例，隨後繼續執行基用例。包含是基用例行爲序列中的顯式語句，因此，位置是隱含的。這與擴展關係不同。
包含只執行一次，通過引用包含的基用例行爲序列中的循環可以達到多次包含的效果。
表示法
虛線箭頭從基用例指向包含用例。箭頭上帶有關鍵字《include》（圖13-106）。位置可以作爲屬性標在箭頭邊上，但通常作爲基用例的文本部分引用，在圖中不表示。圖13-107是基用例行爲序列。
圖13-106 包含關係
圖13-107 用例的行爲序列
165.增量式開發(incremental development)
系統模型和其他產物的開發形成一系列的版本，每個版本完成一定程度上的功能和細化，每個版本都比上一個增加了細節內容。這種方法的優點在於每個新的版本對上一個版本進行少量改動，不易出錯。這種方式與迭代開發概念密切相關。
見開發過程(development process)。
166.間接繼承(indirect instance)
一個實體，該實體是一個元素（如類）的實例，同時又是該元素子的實例。就是說它是一個實例，但又不是直接實例。
167.繼承(inheritance)
通過這種機制使得一個更具體的元素遵從一個更廣泛的元素定義的結構和行爲。
見完整描述符(full descriotor)、泛化(generalization)。
語義
繼承使得可泛化元素的完整描述符能自動通過組裝泛化層次的聲明段構造出來。泛化繼承是一棵模型元素（如類）的聲明構成的樹（實際上是偏序樹）。但每個聲明都不是針對完整可用的元素的，每個聲明只說明該元素比它的祖先增加的內容，繼承就是將這些遞增的聲明組成爲說明實例的完整說明的（隱含）過程，這些完整說明描述實際的實例。
可以認爲每個可泛化元素都有兩個描述符：一個片段描述符和一個完整描述符。片段描述符是模型中元素所聲明的遞增特徵表--例如類聲明的屬性和操作。元素和其父的片段描述符是不同的，模型中不會明確地出現完整描述符。它是元素實例的完整描述--例如類的對象的所有屬性和操作。完整描述符是元素和其父的片段描述符的聯合體。
繼承就是對元素的遞增定義，其他細節如查找算法等等只是特定語言的實現機構，而不是核心定義的一部分。雖然這種解釋看來有點奇怪，但它不需要多數其他定義中的實現過程，同時又與這些定義兼容。
衝突
如果繼承的片段集合中多次出現同一特徵，就可能會出現衝突。繼承集中的屬性只能聲明一遍。如果多次聲明就會導致衝突，說明模型爲非良性結構。（這一限制不是基於邏輯推理，而是爲了防止出現必須用路徑名區分屬性時可能產生的異義）
操作可以被多次聲明，只要聲明相同（方法可以不同），或者子聲明強化了某個繼承聲明（如將子聲明爲隊列或增加它的並行狀態數）。子聲明的方法取代（重載）祖先的方法聲明，不會有衝突。如果從沒有祖先關係的兩個元素中繼承到了不同的方法，則會出現衝突，說明模型爲非良性結構。
討論
泛化是元素之間的類元關係，它解釋了一個元素是什麼；繼承是連接共享遞增聲明，從而形成元素的完整聲明的機構，這兩者是不同的，但有着密切的關係。在泛化關係上應用繼承機構，可以實現說明的分解和共享，以及多態行爲。這是UML和多數面嚮對象語言使用的方式，但是某種程序設計語言還可能採用其他方法。
168.初始狀態(initial state)
轉換的目標狀態是組成狀態的邊界時，用來指明其默認起始位置的僞狀態。
見覆合狀態(composite state)、創建(creation)、入口動作(entry action)、 初始化(initialization)、結合狀態(junction state)
語義
爲了實現封裝，應該儘可能地將組成狀態的外部視圖與內部細節分開。從外部看，組成狀態是隱藏了內部結構的不透明實體，從外部視圖看，轉換的起止點都是狀態自身。從內部視圖看，它們連到狀態內的子狀態。
初始狀態是一個僞狀態，它代表了進入轉換與組成狀態邊界的結合點。它不是真實的狀態，不能保留控制權，它只是說明控制應該轉向哪裏的語法表達式。初始狀態必須要有一個出去的無觸發轉換（沒有事件觸發器的轉換，因此遇到初始狀態可自動有效）。完成轉換連接到組成狀態中的一個真實狀態上。完成轉換上可以有動作，該動作在狀態的入口動作（如果有）之後遇到狀態時執行。除了入口活動（在所有入口處執行，否則缺省）之外，它還允許動作與缺省入口關聯。這個活動可以訪問隱含的當前事件--即由最終使得轉換轉向初始狀態的轉換中的第一片段觸發的事件。
初始狀態不能有帶觸發事件的向外轉換，進入轉換與進入其組成狀態的轉換是一樣的，也應該避免，應該將這種轉換與組成狀態相連。
通常初始狀態上的轉換是無監護條件的，因而必須是來自初始狀態的唯一轉換。多個向外的轉換將帶有監護條件，這些條件必須涵蓋所有的可能性（或者把某個條件設爲"其他"）。關鍵是控制權必須馬上離開初始狀態。它不是真實的狀態，必須激活某個轉換。
類的頂級狀態中的初始狀態，代表了類的新的實例的創建。當執行它的向外轉換時，隱含的當前事件是創建對象的事件，它具有由構造操作傳來的變元值。這些值可供向外轉換上的活動使用。
對象創建
一個類的大多數組成狀態的初始狀態都很類似，它可能帶着標有關鍵字《create》的觸發事件，以及帶參數的有名字的觸發事件。可以有多個此類轉換具有不同觸發事件。當生成類的對象實例時，觸發與其創建操作相應的轉換，該轉換從調用創建操作處得到變元值。
表示法
組成狀態中的初始狀態表示爲小的實心圓，其上可以有向外轉換箭頭。一個組成狀態中只能有一個初始狀態（直接）。但是嵌套的組成狀態中可以有多個組成狀態。
舉例
圖13-108中，我們從狀態X開始，出現事件e之後，激活轉換並執行活動a，轉換指向狀態Y，執行入口活動b之後，初始狀態成爲活動狀態。隨後立即進行外向轉換，執行活動c並進入狀態Z。
如果系統處於狀態X時發生事件f，則激活另一個轉換執行活動d，轉換直接到達狀態Z，這一過程中不包括初始狀態，因爲控制權轉交給Y，所以要執行活動b，但不執行活動c。
圖13-109中的初始狀態帶有分支。假設系統開始於X狀態，當事件e出現時，執行活動a，系統則進入狀態Y並完成入口活動b，控制權轉給初始狀態，測試當前對象的size屬性；如果值爲0，控制轉入狀態Z；如果值不爲0，控制轉入狀態W。
圖13-108 初始狀態
圖13-109 帶有分支的初始狀態
169.初始值(initial value)
說明對象初始化之後某一屬性值的表達式
見默認值(default value)、初始化(initialization)。
語義
初始值是屬性所帶的一個表達式。表達式是一個文本字符串，可以用某種語言進行翻譯。當對帶有此屬性的對象進行初始化，用給定的語言和系統當前值計算該表達式。計算結果用於對新對象中的這一屬性進行初始化。
初始值是可選的，如果沒有，則屬性聲明沒有指出新生對象所帶的值（模型的其他某個部分將提供這一值）
注意，明確的對象初始化過程（例如構造）可以忽略初始值表達式或者覆蓋屬性值。
類範圍屬性的初始值只在執行開始時使用一次，UML沒有規定不同類範圍屬性初始化的相對順序。
170.初始化(initialization)
爲新生成的對象賦值--即其屬性、所屬關係的連接和控制狀態。
語義
概念上，新對象的創建是一步完成的，但將其理解爲兩步會更容易理解：創建和初始化。首先給出空殼對象，它有適當的結構和屬性位置，並賦予了標識符，標識符可以用不同的方法實現，例如包含對象的存儲塊地址，或內部計數器。總之，標識符在系統中是唯一的，可以作爲查找和訪問對象的句柄。到此爲止，對象仍然不是合法的--它違反其值和關係上的約束。下一步是初始化，計算給出的初始值表達式，將結果加入相應的屬性位置。創建方法可以顯式計算屬性值，從而重載默認的初始表達式，結果值必須滿足類的約束。創建方法還可以生成包含新對象的鏈接，它們必須滿足與類有關的關聯多重性的要求。初始化完成後，對象成爲合法的，並應符合其類的所有約束。初始化完成後，屬性或其可變性屬性爲frozen或add only的關聯不能再變化，直到對象被銷燬爲止。這個初始化的操作是原子的，不能被打斷，也不能中途離開。
171.實例(instance)
帶標識符和值的獨立實體。描述符說明具有相似特性的實例集的形式和行爲。實例的標識符和值符合描述符的說明，模型中出現的實例主要是符合描述符模型的實例
見 描述符(descriptor)、標識(identity)、鏈接(link)、對象(object)。
語義
實例帶有標識符。換言之，在系統運行的不同時刻，即使實例的值改變了，該實例可由不同時間點的同一實例來標識。任何時候，實例的值可以是數據值或執行其他實例的指針。數據值是退化形式，其標識符與其值相同，從另一個角度看也可以認爲它沒有標識符。
除了標識符和值以外，每個實例帶有描述符，它用來約束實例可能取的值。描述符是說明實例用的模型元素，UML中大多數模型元素有這樣的雙重特徵，多數元素的主要內容就是各種描述符。此模型的目的就是用系統的實例和實例的值來說明系統可能的不同取值。
每種描述符描述一種實例。對象是類的實例；鏈接是關聯的實例。用例說明可能的用例實例；參數說明可能的變元值，如此類推。某些實例沒有家族名，除非正式設置，往往被忽略，但這並不排除它們的存在。如一個轉該描述一條執行軌跡中狀態的可能出現，若系統中每個實例都是模型中的某個描述字的實例，並且實例集滿足模型中所有顯式和隱式約束，則系統值合法。
模型說明系統可能的取值以及執行過程中從一個值變到另一個值時系統的行爲。系統的值是系統內所有實例以及它們各自值的集合。
模型中的行爲元素說明系統及其中的實例如何從一個值轉變到另一個值。實例標識符的概念對這種說明十分重要。每個行爲步驟以其先前值說明了少數幾個實例值的變化。系統中其餘的實例值不變。例如，對象上的局部操作，可以用對象每個屬性新值的表達式來表示，同時系統其餘部分不變。非局部性的函數可以被分解爲幾個對象上的局部函數。
注意，執行系統中的實例不是模型元素，通常，它們甚至不算是模型的組成部分。模型中的實例作爲典型結構和行爲的解釋或例子出現，是系統取值或運行歷史軌跡的簡短捕捉，這對於人的理解是很有用的，但是它們通常不定義任何東西，只是指示許多可能的取值。
直接實例 每個對象都是某個類的直接實例，也是這個類的祖先的間接的實例。對於其他可泛化元素的實例也是一樣，如果一個類說明某個對象且此類的後代不再說明這一對象，該對象就是此類的直接實例。多重類元中，一個實例可以是多個類元的直接實例，這些類元之間沒有互爲祖先關係。某些執行語義下，由一個類元指明實現類，其他指明角色或類型。完整描述符描述了實例的所有屬性、操作、關聯和其他特徵，它們可以從直接類元處得到，也可以從祖先處繼承得到。多重類元時，完整描述符是每個直接類元的屬性的結合。
創建 見實例創建方式描述的實例化。
表示法
雖然描述符與實例是不同的，但是它們有許多共同的特點，包括相同的格式（因爲描述符必須說明實例的格式）。因此，爲描述符--實例對選擇表示法時應儘可能直接地體現二者的對應關係。實現的方法不多，每種各有優缺點。UML中，將二者用同樣的幾何符號表示，並給實例元素的名字字符串加下劃線。
雖然圖13-110表示的是對象，但下劃線表示法一樣適用於其他實例，如用例實例、構件實例和節點實例。
因爲模型中的實例是作爲例子出現的，通常僅包括與具體例子有關的細節。例如，不必列出完整的屬性表；如果關注的是其他東西（例如對象間的信息流），甚至可以忽略整個屬性表。
圖110 描述符與實例
172.某描述符的實例(instance of)
實例及其描述符之間的關係。
見實例(instance)。
173.可實例化(instantiable)
可以有實例，同義詞：具體(concrete)。
見抽象（abstract）、直接實例(direct instances)、可泛化元素(generalizable element) 。
語義
可泛化元素可以被聲明爲抽象的或是可實例化的。如果它們是可實例化的，就可以創建直接實例。
174.進行實例化(instantiate)
創建描述符的實例。
見實例化(instantiation)。
175.實例化(instantiation)
新模型元素實例的創建。
見初始化(initialization)。
語義
實例是在運行時由原始創建活動或創建操作創建的。首先爲新的實例生成標識符，接着按其描述符的說明生成數據結構，最後由描述符和創建操作者對它進行屬性值的初始化。
實例化使用依賴關係表示了創建實例的類或包含此操作的類與實例化對象所屬類之間的關係。
對象 當對象被實例化（創建）時，被賦予標識符和存儲區，對象被初始化。對象的初始化定義了其屬性值、關聯和控制狀態。
通常，一個具體類有一個或多個類範圍的構造操作，其目的是創建該類的新對象，所有構造操作潛在地創建了一個新的未加工的實例，該實例隨後由構造操作初始化。未加工的實例生成之後，即擁有其描述符所規定的格式，但其值未經初始化。因此，實例初始化之前不能被系統所使用。
鏈接 類似地，鏈接由創建活動或操作創建。它通常是相應類所帶的實例範圍操作，而不是關聯元素自身的構造操作（雖然某些情況下這也是一種可能的實現技術）。同樣有一個創建對象之間新鏈接的潛在的操作，如果一組對象間已存在同類關聯，則操作無效（因爲關聯的內容是一個不能有迭代值的集合）。對普通關聯無須進一步操作，但是關聯類的鏈接還須對其屬性進行初始化。
用例實例 用例實例化意味着創建用例實例，而且用例實例開始執行。用例實例可能先暫時執行有擴展關係或包括關係的其他用例，而後再返回原始用例。當執行到相應用例末端後，用例實例將結束。
其他實例 其他描述符的實例也可以通過類似的兩個步驟生成：首先創建未加工的實例，建立標識符並分配數據結構；按着對新實例的值初始化，使之滿足相應約束。例如，活動是調用操作的直接結果。
創建實體的確切機構是運行時環境的任務。
表示法
實例化依賴關係表示爲虛線箭頭，從執行實例化的類或操作指向被實例化的類；箭頭上標明構造類型《instantiate》
討論
有時用實例化來表示將模板綁定，從而生成綁定元素。但是綁定關係更適合於這種情況。
176.內涵(intent)
描述符結構和行爲特點的正式描述。對比：外延。
見描述符(descriotor)。
語義
描述符（如類和關係）既有描述（內涵），又有其描述的實例集合（外延）。內涵的目的在於用可以執行的方式對實例的結構和行爲進行說明。
177.交互(interaction)
說明對象或其他實例是如何傳遞消息的，交互在合作的語境中定義。
見交互圖(inreraction diagram)。
語義
合作中的對象或其他實例爲了完成某一任務（如執行一個操作）而通過信息交換來進行通信。信息可以包括信號、調用。爲完成一個特定目的而進行的信息交換的模式稱爲交互。
結構
交互是一組對象之間爲完成某一任務（如完成一個操作）而進行的一系列信息交換的行爲說明。爲了說明交互，必須先說明合作--即定義交互的對象及其關係。而後說明可能的交互序列。可以用帶有條件（分支或條件信號）的單描述符或者多描述（每個描述符說明可能的執行路徑中的一條），合作行爲的完整描述可以用狀態機實現，其狀態就是操作或其他過程的執行狀態。
表示法
交互用順序圖或合作圖表示，兩種圖都能表示合作的執行。順序圖明確地表示了合作的行爲，包括信息的時間順序以及方法激活動的顯式表示。但順序圖只表示參與的對象而不表示它們與其他對象的關係和屬性。因此，它不能全面表示合作的語境視圖。合作圖表示交互的完整語境，包括對象及其關係，因此對設計更爲適用。
178.交互圖(interaction diagram)
應用於多種視圖的着重於對象交互的表現方式。包括合作圖和順序圖，二者與活動圖密切相關。
見合作(collaboration) 、交互(interaction)。
表示法
交互圖中表示對象之間交互的方式。交互圖在同一個信息基礎上發展爲不同的形式，各自有不同的側重點。它們是：順序圖、合作圖和活動圖。
順序圖表示按時間排序的交互，着重表現參與交互對象的生命線和它們交換的信息。順序圖不表示對象之間的鏈接。根據目的不同，順序圖有不同的形式。
順序圖有一般形式（說明所有可能的序列），還有實例形式（說明與一般形式一致的一個執行序列）。在沒有分支與循環的情況下，兩種形式是同構的，描述符是其實例的原型。
合作圖表示執行操作的對象間的交互。它類似於對象圖，表示了實現高層操作所需的對象和它們之間的鏈接。
信息的時間順序用信息流箭頭上的序號表示。同步和異步信號都可以用相應的語法表示。順序圖中用箭頭的幾何順序代表時間順序，因此不用序號。有時在順序圖中使用序號是爲了方便，或爲了允許切換到合作圖。
順序圖和合作圖用不同的方式表示了類似的信息。順序圖表示信息的確切次序，更適合於實時說明和複雜的情形。合作圖表示對象之間的關係；更適合於理解對象的全部作用和過程設計。
討論
活動圖表示執行高層操作中的過程步驟。它不是交互圖，表示的是過程步驟之間的控制流而不是對象之間的控制流。側重點在於過程中的步驟。它不表示到目標類的操作的任務。活動圖構造了表示執行中狀態的狀態機。活動圖中的許多特殊圖標與UML基本結構等效，只是受限於附加的限制，提供良種表示可便於使用。
179.交互視圖(interaction view)
表示對象之間爲完成某任務而進行信息交換的視圖，其中包括合作和交互，用合作圖和交互圖表現。
180.接口(interface)
說明元素特有行爲的命名操作集。
見類元(classifier)、實現(realization)。
語義
接口是類、構件或沒有內部結構說明的其他實體（包括包等彙總單元）的外部可見的操作的描述符。每個接口僅描述實際類的行爲的有限部分。一個類可以支持多個接口，效果上或互斥，或覆蓋。接口沒有實現，缺少屬性、狀態和關聯；它只有接收的信號和操作，接口可以有泛化關係，子接口有其祖先的全部操作和所接收的信號。接口可有泛化關係。子接口包括其父所有操作和信號，但可以有附加操作。接口與沒有屬性、方法只有抽象操作的抽象類等價。接口中的所有操作都是公共可見的（否則，不可能引用它們，因爲接口沒有所謂的"內部"來引用它們）。
下列擴展定義說明
.接口是用於說明類或構件的某種服務的操作集合。
.接口用於爲一組操作命名，並說明其信號和效用，接口着眼於服務的效果，而不是結構。接口不爲其中的操作提供實現，接口的操作列表中還可以包括類可以處理的信號。
.接口用於說明服務者爲其他模型元素提供的服務。接口爲一組操作命名，這組操共同實現系統或部分系統的部分行爲。
.接口定義了類或構件提供的服務，它定義的服務由類或構件實現。因此接口跨過了系統的邏輯和物理的界限。一個或幾個類（可能是某個構件子系統的部分）可以提供一個接口的邏輯實現。一個或幾個構件可以提供符合同一接口的物理包。
.如果類實現一個接口，則它必須聲明或繼承接口的所有操作，它也可以有另外的操作（見實現）。如果一個類實現多個接口，它必須包含所有接口的操作。多個接口中可以有相同的操作。如果標誌相符合，就一定是同一操作，否則會發生衝突，說明系統爲非良性結構（實現可以採用語言特定規則來匹配標誌。例如C++中忽略參數名和返回類型）。接口不聲明類的屬性或關係；它是類的實現的一部分。
.接口是可泛化元素，子接口繼承祖先的全部操作並可以有新的操作。實現被視爲行爲繼承；類繼承其他類元的操作，而不是結構。一個類可以實現另一個類。起說明作用的類就象是接口，只有操作部分影響關係。
.接口參與關聯。接口不能作爲關聯的出發點，但可以是關聯的目標；只要該關聯只對接口有導航性。
表示法
接口是一種類元，可以用帶關鍵字《interface》的矩形表示。接口支持的操作列在操作分格中。操作分格中還可以有信號（帶構造類型《signal》）。信號也可列在獨立分格中。屬性分格可以省略，因爲它總是爲空的。
接口還可以表現爲小圓圈，接口名字在圓圈下方。圓圈符號用實線與支持接口的類或其他元素相連，它還可以連向高層的單元，例如包含類的包。這說明類支持接口類型的全部操作（可能更多）。圓圈表示法不表示接口支持的操作，用完整矩形表示法表示操作列表。虛線將接口和使用其操作的類連起來，箭頭指向圓圈。虛線箭頭表示類使用接口中聲明的操作，但用戶類並不需要接口中所有的操作。服務通常用效果測試來說明，如果提供者提供一列接口中的操作，則滿足客戶的需求。
實現關係用帶實心三角形箭頭的虛線表示（虛線泛化關係標誌），箭頭從類指向它支持的接口。這與表示通過實現類來實現類型的方法相同。事實上，這種符號可用於任意兩個類元之間，表示客戶（箭尾）支持提供者（箭頭）定義的所有操作，但不必支持服務者的數據結構（屬性和關聯）
舉例
圖13-111是處理有價證券財政的商業構件的簡化視圖。FinancialPlanner是記錄個人花費與投資的個人財政應用程序。它要有刷新有價證券價格的能力。MutualFundAnalyzer仔細檢查公共基金，需要刷新當前有價證券價格的能力。刷新價格的能力用接口Updateprice表示。有兩個構件實現該接口，用將它們連到接口符號的實線表示。構件ManualPriceEntry允許用戶人工輸入選定有價證券的價格。QuoteQuery通過調制解調器或網從報價服務器上得到有價證券的價格。
圖13-111 接口的提供者和客戶
圖13-112表示作爲類的關鍵字的接口的完整形式。該接口有兩個操作--詢問有價證券的價格並獲得值，提交有價證券價格表並接受改動的價格表，在此例中，QuoteQuery用實線箭頭與接口相連，這與上一圖中關係相同，只是更確切而已。
圖中還有一個新的接口PeriodicUpdatePrices，它是原始接口的子。它繼承了兩個原始操作並增加了一個操作，用請求定期自動刷新價格。該接口由構件QuoteServer實現。它也實現了QuoteQuery中的兩個操作，但方法不同。它不共享QuoteQuery的實現（本例中），因此不繼承它的現實。
圖13-112表示了接口繼承和完全繼承的區別。後者包含前者，但子接口可以用與父接口不同的方法實現，QuoteServer支持QuoteQuery實現的接口（即UpdatePrices），但不能繼承QuoteQueryde 實現（通常，同時繼承實現和接口更爲便利,所以兩種結構常常是等同的）
接口可以包括它能處理的信號列表（圖13-113）。
圖13-112 完整接口表示
圖13-113 帶有信號的接口
接口用於定義類、構件的行爲，而不限制其實現。這樣，允許將接口繼承與實現繼承分開，如JAVA語言的聲明。
181.接口繼承(interface inheritance)
繼承父的接口而非其實現或數據結構。支持接口而不繼承實現的設想通過用實現關係來建立模型實現。
注意，在UML中，泛化關係隱含了接口和實現繼承。只有用私有繼承才能保證只繼承實例而不繼承接口。
見實現繼承(implementation inheritance)、繼承(inheritance)、私有繼承(private inheritance)、實現(realization)。
182.接口說明(interface specifier)
對關聯類要求的行爲的說明，這種行爲用於滿足關聯的內容。它包括指向說明所需行爲的接口、類、或者其他類元的指針。
見關聯角色(association role)，角色名(rolename)，類型(type)。
語義
通常，關聯類的功能不僅支持一個關聯。例如，類可能參與其他關聯，其行爲是所有關聯所要求的行爲之和。應該更明確的說明一個類中支持一個關聯的功能。接口說明符是關聯端上的一個類元，用於說明支持此關聯所用的功能，而不考慮目標類中供其他關聯使用的功能。
接口說明符不是必須的，多數情況下，一個類只參與一個關聯，沒有多餘功能。如果省略接口說明符，關聯擁有對關聯類全部功能的訪問權。
說明符可以是類元集合，每個類元都說明目標類必須支持的操作。目標類必須滿足所有要求，有可能比說明符要求的還高。
表示法
接口說明符語法
角色名：iname表。
iname是代替角色名的接口或其他類元的名字。如果有多個說明符類元，它們的名字用逗號隔開。
舉例：
圖13-114中，Server層將請求存入一個Array類中，爲此，它僅需要Queue類的功能，不隨機訪問信息。實際的Array類滿足接口說明符Queue（包括一個隊列功能的一個數組）的需求，Monitor用一個Array來表示請求的狀態，使用Array的全部功能。
圖13-114 接口說明
討論
使用角色名和接口說明等於創建一個合作，其中僅包含一個關聯角色和兩個類元角色，其結構由原始關聯的角色名和角色類元定義，因此合作使用關聯和類。原始類必須符合接口說明（可以是接口和類型）
183.內部轉換(internal transition)
狀態所帶的有活動的轉換，但它不會引起狀態改變。
見狀態機（state machine）。
語義
內部轉換允許事件引起活動同時不改變狀態，它有初始狀態而無目標狀態，一旦被激活，轉換上的活動將被執行，但狀態不會改變。因此，不執行入口或出口活動。從這方面來看，它與自轉換不同，自轉換會導致退出嵌套狀態，並引發出口或入口動作。
表示法
內部轉換用文字條目列在狀態的內部轉換分格中，條目與外部轉換的文本標籤語義相同。因爲沒有目標狀態，不需要使用箭頭。
事件名字 / 活動表達式
entry、exit、do和include是保留字，不能作爲事件名，它們用來聲明入口活動、出口活動、活動執行或子機構的執行。這些特殊活動使用內部轉換語法是爲了更明顯。它們不是內部轉換，這些保留字也不是事件名。
圖13-11展示表示法。
討論
內部轉換可被視爲一種"中斷"，它引發一個活動但不改變當前狀態，因此不激活出口或入口動作。最好辦法是通過將一個內部轉換連到一個組成狀態來建模一個活動，該活動必須在一些狀態中出現，但不得改變狀態的活動狀態--例如表示幫助信息或事件出現次數計數器。不宜於建模夭折或異常，它們應該用轉入新狀態的轉換來建模，因爲它們的出現與當前狀態不符。
184.不變量(invariant)
一個必須永遠爲真的約束（或者至少在所有活動完成時爲真）。
語義
不變量是一個必須在無活動操作的任何時刻爲真的布爾表達式。它是一種聲明而不是可執行的語句，根據表達式形式的不同，它可以或不可以被事先確定。
見前驅條件(precondition)、後繼條件(postcondition)
結構
不變作爲約束，帶有構造類型《invariant》。
表示法
後繼條件可以表示爲帶《invariant》關鍵字的註釋。註釋附在類元、屬性或其他元素上。
185.迭代表達式(iteration expression)
產生迭代用例集的表達式。每個迭代用例指定迭代中一個活動的執行。迭代用例可以包含對迭代變量的賦值。每個迭代用例只執行活動一次。
見消息(message)
語義
迭代表達式代表條件的或迭代的執行。根據包括的條件，表示0個或多個消息。選擇有：
*[迭代子句] 一個迭代
[條件子句] 一個分支
一個迭代代表一個消息序列，迭代子句表示迭代變量和測試細節，但可以省略（在未確定迭代條件的情況下）。迭代子句用僞代碼或實際的程序設計語言表達。UML沒有說明其格式。可以是
*[I:=1……n]
條件所代表的消息的執行與否依賴於條件子句是否爲真。條件子句用僞代碼或程序設計語言表達。UML沒有說明其格式，可以是
[x > y]
注意，分支與不帶星號的迭代表示法相同，可以將它視爲只出現一次的迭代。
迭代表示法假設迭代中的消息順序執行，它們也可能並行執行，其表示法爲星號加雙豎線。例如：
*[I:=1……n]|| q[i].calculateScore()
注意在嵌套控制結構中，迭代表達式在序號內部層次中不迭代，每層在其語境中定義自己的迭代。
186.迭代開發(iterative development)
包括一系列步驟的系統開發，或稱爲迭代。每個迭代都比前一個更接近所希望的系統。每一步的結果必須是可執行的系統，以供執行、測試和調試。迭代開發符合於遞進式開發。在迭代遞進式開發中，每個迭代爲上一個增加了新的能力。能力增加的順序要考慮到迭代平衡和儘早發現重大風險。
見開發過程(development process)。
187.結合(join)
狀態機活動圖或順序圖中的一個位置，在此處有兩個或以上並列線程或狀態歸結爲一個線程或狀態；一個結合或非分支。反義詞：分支
見覆雜轉換(complex transition)、複合狀態(composite state)。
語義
結合是有多個源狀態和一個目標狀態的轉換。一旦所有源狀態處於活動且發生觸發事件，就執行轉換，目標狀態爲活動的，源狀態必須在並行組成狀態的不同區域中。
表示法
結合表示爲有多個轉入箭頭和一個轉出箭頭的粗線。它可帶有轉換標籤（監護條件，觸發事件和活動），圖13-116是並行組成狀態中的來自多個狀態的一個顯式結合。
討論
見合併(merge)。
188.結合狀態(junction state)
狀態機中作爲一個綜合轉換一部分的僞狀態。它在轉換執行中不打斷運行至完成步驟。
見分支(branch) 、合併(merge)。
語義
狀態機中的轉換可以從源狀態跨過幾個組成狀態的邊界到達目標狀態。執行這種轉換時會激活一個或多個出口/入口活動。某些情況下，有必要將轉換上一個或多個活動與嵌套狀態的出口/入口活動交匯。對只有一個單一活動的簡單轉換而言，這是不可能的。
使多個觸發有單一輸出或允許一個觸發有多個帶監護條件的輸出將會十分便利。
結合狀態作爲一種僞狀態，使得從多個轉換段中建立一個綜合轉換成爲可能。結合狀態可以有一個或多個轉入段和一個或多個轉出段。它不能有內部活動、子機構，或者有觸發事件的向外轉換。它是構建轉換用的僞狀態，因而不能處於"活動"的狀態。
結合狀態可以構建源自多個片斷的轉換。結合狀態鏈中只有第一個段可以有觸發事件，但每個段都可以有監護條件。其後段必須無觸發。有效的監護條件是所有單個監護條件的結合體。除非所有條件被滿足，否則轉換不會開始。換言之，狀態機不會處於結合狀態。
如果多個轉換進入一個結合狀態，它們各自可以有不同的觸發，也可無觸發。通過結合狀態集的每條路徑代表了一個不同的轉換。
向外的轉換也可以有監護條件。如果有多個向外轉換，每個必須有獨自的監護條件，這就是分支。
向外轉換可以附帶活動（結合狀態可以有一個內部活動，但它等價於將一個活動連到向外轉換）。一旦所有監護條件滿足，活動將被執行。轉換不能部分激發而停在結合狀態，必須到達某個常規狀態。
當轉入的轉換激活後，向外的轉換會立即被激活，隨即執行附帶的活動。轉入和向外的轉換是一個原子步驟（運行到結束步驟）的部分--它不能被任何活動或事件中斷。
表示法
狀態機中用小圓圈表示結合狀態。它沒有名字，可以帶有向內和向外的轉換箭頭。
舉例：
圖13-117是狀態S到T的兩個完整轉換--由事件f觸發的單段轉換和事件e觸發的多片斷轉換。圖中還表示了入口/出口活動。
注意，轉換線上的活動標籤的位置沒有意義。如果活動d畫在狀態x中，它將在x退出y進入之前執行。因此，d應畫在轉換上的最外面的位置.
圖13-179和圖13-184表示了其他例子。
見控制圖標等狀態圖和活動圖中可能出現的符號
189.關鍵字(keyword)
關鍵字是爲沒有獨立語法的模型元素類元用的文字。
見圖形標誌(graphic marker)、構造類型(stereotype)
表示法
關鍵字用於沒有單獨表示法的內置模型元素和用戶定義的構造類型。通常將關鍵字寫在書名號內。
《關鍵字》
如果帶關鍵字的符號有一定大小，則將關鍵字打在符號邊界內。
某些預定義關鍵字在本文中說明，並用保留字的方式表示。其他可供用戶作爲構造類型使用。不能使用與預定義關鍵字相同的構造類型。
討論
容易區別的符號是有限的，因此UML表示法用文本關鍵字來區別同一主題下的不同變體，包括基類的元模型子類、元模型基類構造類型，以及表元素組。對用戶而言，元模型子類和構造類型間的元模型區別並不重要，但它對工具製造者和實現元模型建立者而言是重要的。
190.標籤(label)
在圖中使用字符串的一種方法，僅僅是表示法。
見圖(diagram)。
表示法
標籤是圖中在邏輯上附屬於另一個符號的圖形字符串。通常將字符串標在符號邊上或封閉區域內來表示這種附屬關係。對某些符號而言，標籤位置是確定的（如在線下）。而對多數符號而言，標籤必須靠近線或目標。編程工具可以維持標籤和圖形符號之間的內部聯繫，這樣即使標籤和圖形符號分開表示，二者在邏輯上也是相連的。在最終視圖中必須都表示清楚，以保證符號和標籤連接關係不會產生混淆。雖然圖中並不一定能完全清楚的表示附屬關係，但這種關係在圖的結構層次上是清晰無異議的。工具可以用其他方法表示標籤與符號之間的附屬關係（如着色線或匹配元素閃爍）。
191.語言類型(language type)
用編程語言的語法定義的匿名數據類型。
見數據類型(data type)。
語義
類型是一種作爲由編程語言翻譯成數據類型的表達式。它可以爲屬性、變量、參數的類型。它沒有名字，不能用於聲明新的數據類型。
例如，c++數據類型"Person*(*)(Contract*,int)"可被定義爲C++語言類型。
語言類型的目的是編程語言中的實現。更多的邏輯關係應該用關聯實現。
192.層(layer)
將模型中同一抽象層次的包分組的一種結構模式，每個層在某個實現層次上代表一個虛擬世界。
193.葉(leaf)
在泛化層次結構中，沒有子的可泛化元素，它必須是供使用的具體（整體實現的）實體。
見抽象(abstract)、具體(concrete)。
語義
葉屬性聲明一個元素必須爲葉。如果聲明瞭葉的子，說明模型爲非良性結構。其目的是保證類不被修改。例如，類中行爲必須完整的，這樣纔有實際意義。葉聲明還允許將系統不同部分的編譯分開，它保證方法代碼不被重載，以及方便方法代碼的嵌入。葉屬性爲假的元素可能實際上是葉，但它可以在將來修改模型時生成子。視爲葉或者被限定爲葉不是基本語義屬性。
194.生命線(lifeline)
順序圖中的虛線，用來表示對象在一段時間內存在，此線與時間軸平行。
見順序圖(sepuence diagram)。
語義
生命線表現了對象存在的時段。對象在擁有控制線程時激活--即作爲線程的根時。被動的對象在控制線程通過時暫時存在--被外部調用時。後者稱爲活動，它的存在時間包括過程調用下層過程的時間。
表示法
對象或類元在順序圖中表示爲垂直虛線，稱爲生命線。生命線表示對象在特定時間段內存在。
生命線間的箭頭代表對象之間的消息，指向生命線箭頭表示對象接收信息，由一個操作完成，箭尾表示對象發送信息，由一個操作激活。生命線之間箭頭排列的幾何順序，代表了消息的時間順序。
如果對象在順序圖表示的時間段內創建或消亡，其生命線就在相應時間點開始或終止。否則，生命線貫穿圖的始終。對象符號畫在生命線上。如果對象在圖中被創建，則對象符號畫在創建它的消息上，否則，對象符號畫在任何消息箭頭上。如果對象在圖中被銷燬，用大X表示銷燬，X或者標在導致銷燬的消息的箭頭上，或被銷燬對象的最終返回消息（自毀）上。轉換開始時存在的對象畫在圖的頂部（第一個箭頭上方）。轉換結束後仍存在的對象，生命線畫過最後一個箭頭。
生命線可分爲兩條或是更多，以表示條件控制。每條軌跡對應消息流的一個分支。生命線也可在某一點結合，見圖13-162。這種表示法易引起混淆，應小心使用。
對象永久或暫時活動的時期用一條實線表示生命線。第二條雙線表示迭代。祥見激活。因爲主動對象總是活動的，有時省略雙線。
生命線被狀態符號中斷表示狀態轉換，這與合作圖中的成爲轉換相應。指向狀態的箭頭表示引起狀態變化的消息。見圖13-163
195.連接(link)
對象引用元組，是關聯或關聯角色的實例。
語義
連接是兩個或多個對象之間的獨立連接，它是對象引用元組（有序表），是關聯的實例。對象必須是關聯中相應位置處類的直接或間接實例。一個關聯不能有來自同一關聯的迭代連接，即兩個相同的對象引用元組。
作爲關聯類實例的連接除了對象引用元組外還可以有屬性值表。不允許具有相同元組對象引用的迭代連接，無論其上的屬性是否不同。連接的標識符來自對象引用元組，它必須是唯一的。
連接可以用於導航。換言之，連接一端的對象可以得到另一端的對象，也就可以發送消息（稱通過聯繫發送消息）。如果連接對目標方向有導航性，這一過程就是有效的。如果連接是不可導航的，訪問可能有效或無效，但消息發送通常是無效的，相反方向的導航性另外定義。
合作中，關聯角色是語境有關的暫時的類元之間的關係，關係角色的實例也是連接，其壽命受限於與合作的長短。
表示法
連接表示爲對象間的路徑--一個或多個相連的線或弧。在可變關聯中，路徑是兩端指向同一對象的迴路。表示實例的名字有下劃線。連接沒有實例名，它的標識符來自相關的對象，因爲實例沒有多重性，連接也沒有多重性。多重性是說明可以存在的實例數目的標識符。連接角色上可以表示其他關聯修飾（聚集、組成、導航）。
連接上可以表示限定詞，限定詞的值可以表示在盒中，
圖13-118有常規連接和限定詞連接.
連接還可以表示關聯的屬性，如導航方向、聚集、組成、實現構造類型和可視性。
N一維連接 n維連接用菱形表示，引出到每個參與對象的路徑，其他表示與上文相同。
討論
對象圖如何表示依賴關係？通常，依賴代表類之間的關係並在類圖中表示，而不在對象圖中表示。過程變元、局部變量和操作調用應作爲實際的數據類型出現而不僅僅是依賴關係。因此，它們可以表示爲連接調用者要得到目標對象過程的指針--這就是連接。有些連接是合作中關聯角色的實例，如變元和局部變量。記住：依賴與類相關，而不是與各個對象相關。
196.連接端(link end)
關聯端的實例。
197.列表(list)
由另一個模型元素擁有且嵌套其中的長度可變的有序模型元素序列。
見類元(classifier)、狀態(state)。
語義
類元有許多子列表，包括屬性，操作和方法。狀態有內部轉換列表。其他元素有其他元素列表。每種列表獨自說明。通常用這種技術說明嵌入表的屬性。除了屬性和操作列表外，可用其他列表說明預定義或用戶定義的值，如責任、角色或修改歷史。UML沒有定義這些可選列表，由用戶定義的列表操作依賴於工具。
嵌入列表和其中的元素要麼屬於包含類，要麼屬於其他包含元素。多個包含元素不能共享所有權。其他類可以訪問列表中的元素--例如通過繼承或關聯，但只有直接包含元素有所有權和修改權。這些列表元素連同包含元素一同存儲、複製和銷燬。
列表元素的順序由建模者決定。這種順序會很有用--例如，可作爲生成編程語言聲明序列的代碼生成器。如果建模者不關心順序，可能因爲模型處於分析階段或因爲語言與順序無關，這種順序雖仍在存在但可以忽略。
表示法
嵌入列表在獨立的分格中表現爲字符串列表，每個元素對應一行字符串。每個字符串是特徵的編碼表示，如屬性、操作、內部轉換等等。編碼種類由每種元素說明。
排序 字符串的順序和列表中的元素的順序一致，但內部存儲順序可能並非如此，字符串存儲可能依賴於某種內部屬性，如名字、可視性或構造類型。注意：每項仍維持它在基本模型中的順序。排序信息僅僅在視圖中忽略。
省略號 省略號（…）作爲列表末尾的元素表示模型中還有符合條件的元素，但未在表中列出。在其他視圖中，可能列出這些元素。
構造類型 列表元素可以有構造類型。構造類型關鍵字寫在列表元素前面。
屬性字符串 屬性字符串說明元素的屬性。在元素之後的大括號內，用逗號分隔列出屬性和約束。
組屬性 一組列表元素可以有屬性或構造類型。如果單獨的一行中出現構造類型、關鍵字、屬性字符串或約束，則此行不表示一個列表元素。而是此後所有元素共同的屬性，如同它們直接作用於每一行一樣。默認效果持續到出現表中另一組屬性爲止。插入帶有一個空關鍵字（《》）的一行可以撤銷所有組屬性，但將不受限於組屬性的所有項置於表頭，會更明瞭些。
圖13-119表示了作用於多個元素的構造類型。
注意：組屬性只是一種方便的表示法，每個模型元素仍帶有各自的屬性值。
分格名字 分格可以有名字，用特殊字體（如小寫黑體）表示，標在分格頂上。如果有省略或新增加的用戶自定義的分格，這種標誌就十分有用。對類而言，預定義的分格名爲attributes和operations。用戶定義的分格可能是requirements。類的名字分格必須有，因此不需要也不允許分格名字。圖13-119和
圖13-120表示命名分格。
表示選項
排序 工具可能按存儲順序列出表元素。此時，看不到元素的繼承順序。順序基於某些內部屬性，不表明額外建模信息。典型排序包括字母順序、構造類型順序（構造函數、析構函數，以及一般方法），按可視性排序（公共、保護到私有）,等等。
篩選 列表元素可以按照某些規則篩選。選擇規則的說明是工具的責任。如果篩選列表爲空，說明沒有符合要求的元素，但原始表可能或不可能包含不滿足規則從而不可見的其他元素，工具應負責是否說明局部和全部篩選以及如何說明。還可以用單獨的圖來對此說明。
如果省略一個分格，則不能確定其中的元素的存在與否。空的分格說明沒有符合篩選條件的元素。
注意：屬性也可以通過組成表示（圖13-71）
198.位置(location)
一個運行時實體在某環境中的物理放置，如分佈式環境中的對象或分格。在UML中，位置是分散的，位置單位是節點。
見構件(component)、節點(node)。
語義
位置的概念需要實體存在空間的概念。UML沒有建立三維空間，而是提供了由通訊路徑連接的拓撲模型空間。節點是運行時實體可以存在的計算資源。節點之間用通訊路徑相連，實體的定位就是分配節點指針。在節點上，有些實體存在於其他嵌入實體內。例如，對象存在於構件或其他對象中，這些實體的位置就是其包含實體的位置。
對象或構件實例可以移動到新的位置上。這可以通過"成爲（become）"關係表示，"成爲"意味着在某一時刻第一個實體被第二個實體代替，而第二個實體原來在另一個位置上。
表示法
實體（包括對象、構件實體和節點實體）的位置在另一個實體之內可以用物理嵌套表示，
如圖13-121所示。包含關係也用組成箭頭表示。或者實例可以有一個location標記的屬性，其值爲包含元素的名字。
如果對象在交互中移動，它可以表示爲多個版本，版本間用become轉換相連。見圖13-121。become箭頭可以有序列號，說明對象移動的時間。每個對象符號代表時間段對象的一個版本。消息必須與正確的對象版本相連（圖13-117）。
199.許多(many)
多重性0 ..* 的縮寫--0個或無限多個。換言之，大小不限。
見多重性(multiplicity)
200.成員(member)
類元的已命名結構化繼承組織的名字，可以是屬性、操作或方法。每個類元可以有0個或多個各種成員。特定種類成員的列表以字符串表的形式表示在類元符號的分格中。
見列表(list)。
201.合併(merge)
狀態機中的一個位置，兩個或多個可選的控制路徑在此匯合或"無分支"。反義詞：分支。
見 結合狀態(junction state)
語義
合併是指兩個或以上控制路徑匯合的情況。在狀態機中，一個狀態有多個轉入轉換。沒有提供合併的特定模型構造。如果它是單一運行至完成步驟的一部分，則可以由結合狀態表示。
表示法
在狀態圖、順序圖或活動圖中。合併表示爲帶有多個輸入箭頭和一個輸出箭頭的菱形。不需要條件，見圖13-122。
菱形也用於分支（與合併相反），但不會混淆。因爲分支有一個輸入箭頭和多個輸出箭頭，並且都有監護條件。
可以結合分支與合併，但用處不大。它可以有多個輸入和多個帶標籤的輸出。
注意：合併只是一種便利的表示法，省略它不會丟失信息。合併和分支常常成對使用。
圖13-122 合併
討論
請區分合並和結合，合併匯合了兩個以上的控制路徑。在任何執行中，每次只走一條，無需同步。
結合匯合了兩條或以上的並行控制路徑。在任何執行中，所有路徑都要走過，當它們都到達結合的源狀態時，結合才被激活。
202.消息(message)
從一個對象（或其他實例）到另一個對象傳遞消息，除非活動可以保證這一點。消息可以是信號或調用操作，收到消息實例被認爲是收到事件的實例。
見調用(call)、合作(collaboration)、交互(interaction)、操作(operation)、發送(send)、信號(signal)。
語義
消息是從一個對象（發送者）向另一個或幾個其他對象（接收者）發送信號，或由一個對象（發送者或調用者）調用另一個對象（接收者）的操作。消息的實現有不同方式，如過程調用、活動線程間的內部通訊、事件的發生等。在邏輯層次上，發送信號和調用操作是類似的，都激活發送者和接收者之間的通訊，接收者收到一個值，並由此判斷應該幹什麼。調用可以視爲一種信號，激活一個發送，顯式帶有一個指針變元，隨後返回的信號由它帶回返回值。在實現層次上，信號和調用各有不同的屬性和行爲，因此是不同的UML元素。
收到信號可能引起接收者狀態機的轉換。接收者有兩種不同的調用處理方式可以選用（由接收者的模型決定方式）。操作作爲過程體（方法）實現，當信號到來時它將被激活。過程執行完後，調用者收回控制權，並可以收回返回值。另一種方式是主動對象，操作調用可能導致調用事件，它觸發一個狀態機轉換。這種情況下，沒有方法體，但轉換可以有動作，轉換也可爲調用者提供一個返回值。轉換完成後或調用事件未觸發轉換時，調用者收回控制。
消息中帶有目標對象表達式的集合。消息發往集合中的所有對象。除非另行說明（有約束），消息將並行地送往所有對象。這說明執行的順序是不定的，可以是並列的。如果必須按照一定順序發消息，它們應該循環發送。對於調用，所有調用完成後，調用者收回控制。
發送消息的時間可以用列在消息名字上的表達式表示。
見時間標誌(timing mark)。
結構
消息有發送者、接收者和活動。
在交互中，發送者是發出消息的類元角色。接收者是接收到消息的類元角色。活動爲調用、信號、發送者的局部操作或原始活動，如創建或銷燬。活動帶有參數表、接收者列表、以及指向激活的操作或信號的指針。還可以有消息執行的條件或迭代說明。
在交互中，消息之間有前驅-後繼關係和調用-被調用的關係，後者適用於過程方法。每次調用增加一個嵌套層次。在調用中，消息是有序的，可以並行。
前驅-後繼（順序）關係將線程上的消息組織爲一列。一個消息可以有多個前驅或者後繼。如果兩個消息之間沒有順序關係並且沒有共同的前驅，它們就可以並行。如果一個消息有多個前驅，只有在所有前驅完成後，該消息才能執行。這種消息是一個同步點。
調用-被調用（激活）關係定義了嵌套的過程結構。調用過程（使用調用事件）的消息是被調用者的過程體內所有消息的激活者。其中，被調用消息也有前驅-後繼關係，由此確定相對順序（允許並行）。
如果消息爲調用，在調用過程完成並返回之前，調用者將鎖定。如果接收者將消息處理爲調用事件，初始轉換完成後就出現返回值，此後調用者收回控制，被調用過程繼續執行。
順序和激活關係只涉及同一個交互中的消息。
表示法
順序圖和合作圖的表示法不同。
順序圖(Sequence diagram)
順序圖中，消息表示爲從一個對象（發送者）的生命線指向另一個對象（目標）的生命線的實線箭頭。與外部消息相比，如果箭頭和生命線垂直，說明消息發送是即刻的，至少是很快的。如果箭頭傾斜，則說明消息的傳送有一定的時間延遲，其間可以傳送其他消息。對象發給自身的消息，箭頭的起點和終點都是同一條生命線。消息按時間順序從頂到底垂直排列。如果多條消息並行，它們之間的順序不重要。消息可以有序號，但因爲順序是用相對關係表示的，通常省略序號。
傳遞延遲 消息箭頭通常是水平的，說明傳遞消息的時間很短，在此期間不會"發生"其他事件。對多數計算而言，這是正確的假設。如果消息的傳送需要一定時間，在此期間可以出現其他事件（來自對方的消息到達），則消息箭頭可以畫爲向下傾斜的。
分支 從同一點發出多個箭頭表示分支，每個箭頭有監護條件。根據條件是否互斥，有條件型和並列型兩種結構。
重複 相連的一系列消息可以被封裝並標爲重複的，重複標誌說明這組消息可以多次出現。對過程而言，重複執行的條件列在重複的下方。如果有並行，則可能有某些消息是重複的部分，有些只執行一次。
合作圖(Collaboration diagrams)
在合作圖中，消息表示爲帶有標籤的箭頭，附在連接發送者和接收者的路徑上。路徑用於訪問目標對象，箭頭沿路徑指向接收者。如果消息發送給對象本身，箭頭指向對象自己，並標有關鍵字《self》。一個連接上可以有多個消息，沿相同或不同的路徑傳遞。順序由序號表明。
雙視圖(Both diagrams)
消息箭頭上標有消息名字（操作或信號名）以及參數值。消息上還可以有序號，表示它們在交互中的作用。順序圖中箭頭的物理位置表明了相應的順序，可以省略序號。合作圖中必須有序號。序號可以表明並行線程，這對兩種圖都有用。消息還可以有監護條件。
控制流類型 下列不同的箭頭形狀表示不同的控制流。
實心實線箭頭
過程調用或其他嵌套控制。外層序列從新開始之前，應該完成所有內層序列。可以用於常規過程調用。也可用於並行活動狀態。表示其中一個狀態發送了信號，並在等待嵌套行爲序列完成。
棍狀箭頭
平面控制流，每個箭頭表示下一個執行順序。對於嵌套過程，它對應於搜索葉節點的向底掃描活動。
半個棍狀箭頭
異步控制流。與棍狀箭頭不同，用於表示兩個對象之間按順序執行的異步消息。
虛線棍狀箭頭
從過程調用返回，返回箭頭可以忽略。因爲它是隱含在活動
結束時的。
其他變體
可以表示其他控制種類，如"超時"、"中止"等。這些是UML核
心之外的擴展。
消息標籤 語法如下：
標籤說明發送的消息、參數和返回值，以及大型交互中消息的順序，包括調用嵌套、分支、分支、並列和同步等。
前驅 合作中，前驅列出的序列號用逗號隔開，並後跟反斜線（/）。
序號列表/
如果列表爲空，則省略該條目。
每個序號是一個無任何迭代項的順序表達式，它必須與其他消息的序號相匹配。
這表示在列表中的所有序號代表的消息出現之後本消息才能發送（一個線程跨越所要求的消息流，監護條件仍然滿足）。因此，監護條件表示線程同步。
注意：序號在某個消息之前的消息是它的默認前驅，不用特別列出。同一前綴的消息序號構成序列。數字前驅是指該序號最後一位少1，即消息3.1.4.5是 3.1.4.6的前驅。
順序圖中，可視的順序決定序列。對象發送自身的任何消息之前出現發給自身的多個消息，表示同步。
序號表達式 序號表達式是順序子句列表，之間用冒號（：）隔開。每個子句代表交互中一個嵌套層次。如果所有控制並行，則無嵌套。語法如下：
標籤 循環opt
其中標籤是整數或者名字
整數代表消息所在層次。例如消息3.1.4在活動3.1的消息3.1.3之後。
名字代表併發控制線程。例如：消息3.1a和3.1b在3.1中並行。所有並行控制線程在同一嵌套層次上深度相同。
循環代表條件或迭代執行。表示根據條件執行0個或多個消息。選擇有：
*[迭代子句] 迭代
[條件子句] 分支
迭代代表了給定深度上的消息序列。[迭代子句]可以省略（未指定迭代條件）。[條件子句]用僞代碼或程序設計語言實現。UML沒有說明其形式。可以爲：*[i:=1..n]。
條件表示一條消息的執行取決於條件子句是否成立。條件子句用僞碼或程序設計語言實現。UML沒有說明其形式，例如：[x>y].
注意：分支與迭代的表示法一樣，只是沒有*號。可以視爲執行一次的迭代。
表示法假設其中的消息將順序執行，也可能並行執行，用雙豎線表示（*||）。
簽名 是說明名字、屬性、操作返回值、消息或信號的字符串。有下列屬性：
返回值列表
說明交互中消息返回值的名字，名字之間用逗號隔開。它可以作爲後續消息的參數。如果消息不返回值，則省略返回值和賦值操作。
消息名字
目標對象中引發的事件名字（通常是要求執行操作的事
件）。可以用不同的方式實現，其中之一是操作調用。若實現爲過程調用，它就是操作名。操作必須在接收方的類中定義或繼承。其他情況下，它可以是接收方引發的事件名字。通常用消息名字和參數表都來確定一個操作。
參數列表
括號中用逗號隔開的參數表。空表也可以使用括號。每個參數是使用僞代碼或適當編程語言寫出的表達式（UML中未說明）。表達式可以使用以前消息（同一作用域）的返回值和起源於同一對象的導航表達式（即其屬性、發出的鏈接和可達路徑）。
舉例
下文爲控制消息標籤語法
2:display(x,y) 單個消息
1.3.1:p:=find(specs) 帶返回值的嵌套調用
[x<0] 4:invert(x,color) 條件消息
3.1*:update() 迭代
A3,B4/C2:copy(a,b) 與其他線程同步
表示選項
在消息邊上表示數據標記，可以代替參數和返回值的文本表達
（圖13-123）。標記是標有參數或者返回值的小圓圈，其上的箭頭指向消息的方向（參數）或反方向（返回
值）。標記代表了返回值和參數。文本和標記兩種表示法都可以使用，但是文本方式更簡練，建議使用。
消息語法由編程語言的語法說明，如C++或Smalltalk語言。但視圖中的所有表達式應使用同一種語法。
203.元類(metaclass)
這種類的實例是類，通常用於構造元模型。元類可以用關鍵字《metaclass》建模爲一個類的構造類型。
見強類型(powertype)。
204.元-元模型(meta-metamodel)
定義了表達元模型使用的語言的模型。元-元模型與元模型之間的關係類似於元模型與模型之間的關係。這一層次通常僅僅與工具建造者、數據庫建立者有關。UML就是一種稱爲元對象機制（Meta-Object-Facility，簡稱MOF)的元-元模型定義的。
205.元模型(metamodel)
定義表達模型所用語言的模型，是元-元模型的實例。UML元模型定義了UML模型的結構。
206.元對象(metaobject)
元模型語言中所有實體的統稱，例如：元類、元類型、元屬性、元關聯。
207.元關係(metarelationship)
關係描述符及其實例關係的統稱，包括實例關係和強類型關係。
208.方法
操作的實現，說明生成操作結果的算法或過程。
見具體（concrete）、操作(operation)、關係(realization)
語義
方法是操作的實現。如果操作不是抽象的，它就必須有方法或調用事件，或定義在具有操作的類上，或從組類繼承。方法用過程表達式說明，是特定語言書寫的字符串（如C++、SmallTalk或自然語言），用來說明算法。語言應與目的相適應。例如：自然語言適於早期分析，不適用於生成代碼。
除非操作聲明爲抽象的，否則操作聲明隱含方法的存在。泛化繼承中，每次迭代聲明的方法重載了同一操作中的任何繼承方法。
注意，方法是可執行的過程--一種算法--而不是結果說明。例如，事前-事後說明不是方法。方法受制於算法、計算複雜性和封裝的實現和地址分配問題。
在某些方面，方法的屬性會比其操作更嚴格。操作沒有定義爲查詢，但方法可以聲明爲查詢。如果操作定義爲查詢，則方法必須是查詢。同樣的，方法可以強化並行屬性。順序操作可以被實現爲條件控制或者並行的方法。此時，方法符合操作的聲明，只是加強了其中的約束。
表示法
方法用操作聲明表示，只是沒有抽象特徵（圖13-124）。如果操作是繼承的，迭代操作的聲明的一般形式（非書寫體）表示法，給出具體操作。方法體的文字表示爲註釋，連到操作表項。圖中通常不表示法體，它們對文本編輯器是隱藏的，可用命令行方式呈現。
209.模型(model)
系統語義的完整抽象。
見包(package)、子系統(subsystem)。
語義
模型是從一個特定視點對系統進行的或多或少的完整抽象。說它是完整的，因爲它從給定視圖全面地描述了系統或實體。提供獨立視圖的模型可以獨立維護。
模型可以分解爲包的層次結構。最外層的包對應於整個系統。模型的內容是從頂層包到模型元素的包含（所有）關係的閉包。
模型還可能包含一部分系統環境，表示爲行爲者和界面。特別可以建立環境與系統元素的對應關係。系統及其環境構成了更高層次上的系統。
不同模型中的元素彼此沒有直接影響。但它們可能代表了同一概念的不同層次、細節或開發步驟。因此，它們之間的關係，如跟蹤或細化，對開發過程十分重要，往往會影響重要的設計決定。
表示法
模型可以表示爲包，並帶有構造類型《model》。但表示法中沒有什麼細節來表示模型。工具可以表示模型列表，但是其間很少有關係。最有用的是將模型名字變爲其頂層包的名字，或者其中所有內容的映射。
討論
沒有一種系統視圖或系統本身可以稱爲完全的，因爲系統總能與外界有某種模型中沒有表示的聯繫。因此，封裝模型是一個相對的概念，必須指定實際工作的需求。
UML模型是一種包，它着重於某個視圖。每個模型有自己的層次，可以與系統其他視圖的層次相同或不同。
210.模型元素(model element)
從建模的系統中抽象出來的元素。與表達元素不同，表達元素（通常可視）是一個或幾個與人交互的模型元素。
語義
所有有語義的元素都是模型元素，包括現實世界的概念和計算機系統中的概念。表現模型爲目的的圖形元素是表達元素，不是模型元素，因爲其中不含有語義信息。
模型元素可以有名字，不同類型元素的名字的使用和限制不同，下面將分別說明。每個模型元素有與其類型的相符的命名空間。所有模型元素可以有下列屬性。
標籤值
任何模型元素或表達元素可以帶有0個或多個標籤-值對。標籤是說明值的含義的名字。標籤在UML中不是固定的，但可以擴展，從而表示各種建模者或編程工具有用的信息。
約束
模型元素可以有0個或多個約束。約束是用約束語言語言串表達的限制條件。
構造類型
模型元素可以與0個或多個構造類型名字相關，只要構造類型應用於基模型元素。構造類型不改變基類結構，但是可以爲有該構造類型的元素增加標籤
此外模型元素可以參與依賴關係。
見第14 章標準元素(Standard Elements)，預定義的標籤表(a list of predefined tags)、約束(constraints)、構造類型(sterotypes)。
211.模型管理視圖(model management view)
模型的這一特徵將自身組織爲結構化的部分--包、子系統和模型。這種視圖有時作爲靜態視圖的一部分，通常與靜態視圖類圖組成使用。
212.建模時間(modeling time)
出現於軟件開發過程中建模活動中，包括分析和設計。使用注意：討論對象系統時，區分建模時間與運行時間是非常重要的。
見開發過程(development process)、建模步驟(stages of modeling)。
213.模塊(module)
存儲和操作用的軟件單元，包括源代碼模塊、二進制代碼模塊和可執行代碼模塊。它不與個別UML結構相對應，而是包含幾個結構。
214.多對象(multiobject)
指明多個對象集合而非單對象的類元角色。
見類元角色(classifier role)、合作(collaboration)、消息(message)。
語義
多對象是代表多個對象的類元角色，多個對象通常在關聯的"許多"端。多對象在合作中使用，表示以一對象集而非單對象爲單元的操作。例如：在對象集中查找一個對象的操作作用於整個集合而非個別對象。這種分組不影響系統基本的靜態模型。
表示法
多對象用兩個矩形表示，上面的矩形偏向斜下方，表示有許多矩形（圖13-125）。指向多對象的符號的消息箭頭表示送往這些對象的消息。例如：查找一個對象的選擇操作。
要對相關對象集中每個對象執行操作，要有兩個消息：一個迭代消息生成指向個個對象的路徑，另一個消息通過這些路徑（暫時）發送消息。圖示中可簡化爲，消息合併爲一，包括一個迭代和對每個對象的應用。目標角色名的描述爲"許多"（*），表示有多個隱含的連接。雖然可將它寫爲單個消息，但它在基本模型中（及在任何實際代碼中），需要兩層結構（操作連接迭代，使用連接消息）。
來自集合的對象表示爲常規的對象符號，並用組成鏈與多對象相連，表示它屬於集合。指向單個對象符號的箭頭表示發給單個對象的消息。
典型地，發給多重對象的選擇消息返回指向某一對象的指針，隨後原發送者再向它發送消息。
215.多重類元(multiple classification)
泛化的一種語義變體，其中一個對象可以直接屬於多個類。
語義
它是一種語義變體，其中對象可以是多個類的直接實例。與動態類元共同使用時，對象可以在運行時獲得/失去類。它允許類代表對象承擔的臨時角色。
雖然多重類元符合常見的邏輯關係，但卻給編程實現造成了困難，常用的語言不支持多重類元。