UML的9種圖例的定義、用途、畫法總結(jié)

1、UML的9種圖例的總結(jié)一、 用例圖1、 定義用例定義：用例是對包括變量在內(nèi)的一組動作序列的描述，系統(tǒng)執(zhí)行這些動作，并產(chǎn)生傳遞特定參與者的價值的可觀察結(jié)果。（這是UML對用例的正式定義，可以這樣去理解，用例是參與者想要系統(tǒng)做的事情，用例在畫圖中用橢圓來表示，橢圓下面附上用例名稱）。用例圖定義：由參與者（Actor）、用例（Use Case）以及它們之間的關(guān)系構(gòu)成的用于描述系統(tǒng)功能的動態(tài)視圖稱為用例圖。2、 用途用例圖（User Case）是被稱為參與者的外部用戶所能觀察到的系統(tǒng)功能的模型圖，呈現(xiàn)了一些參與者和一些用例，以及它們之間的關(guān)系，主要用于對系統(tǒng)、子系統(tǒng)或類的功能行為進行建模。用例圖主要的

2、作用有三個：（1）獲取需求；（2）指導(dǎo)測試；（3）還可在整個過程中的其它工作流起到指導(dǎo)作用。3、 組成元素以及元素之間的關(guān)系說明用例圖由參與者（Actor）、用例（Use Case）、系統(tǒng)邊界（用矩形表示注明系統(tǒng)名稱）、箭頭組成，用畫圖的方法來完成。參與者不是特指人，是指系統(tǒng)以外的，在使用系統(tǒng)或與系統(tǒng)交互中所扮演的角色。因此參與者可以是人，可以是事物，也可以是時間或其他系統(tǒng)等等。還有一點要注意的是，參與者不是指人或事物本身，而是表示人或事物當時所扮演的角色。系統(tǒng)邊界是用來表示正在建模系統(tǒng)的邊界。邊界內(nèi)表示系統(tǒng)的組成部分，邊界外表示系統(tǒng)外部。系統(tǒng)邊界在畫圖中用方框來表示，同時附上系統(tǒng)的名稱，參與

3、者畫在邊界的外面，用例畫在邊界里面。因為系統(tǒng)邊界的作用有時候不是很明顯，所以我個人理解，在畫圖時可省略。 箭頭用來表示參與者和系統(tǒng)通過相互發(fā)送信號或消息進行交互的關(guān)聯(lián)關(guān)系。箭頭尾部用來表示啟動交互的一方，箭頭頭部用來表示被啟動的一方，其中用例總是要由參與者來啟動。元素之間的關(guān)系： 用例圖中包含的元素除了系統(tǒng)邊界、角色和用例，另外就是關(guān)系。關(guān)系包括用例之間的關(guān)系，角色之間的關(guān)系，用例和角色之間的關(guān)系。 角色之間的關(guān)系 ：角色之間的關(guān)系。由于角色實質(zhì)上也是類，所以它擁有與類相同的關(guān)系描述，即角色之間存在泛化關(guān)系（泛化關(guān)系可以先簡單理解為繼承），泛化關(guān)系的含義是把某些角色的共同行為提取出來表示為通用

4、的行為。 用例之間的關(guān)系： l 包含關(guān)系： 基本用例的行為包含了另一個用例的行為。基本用例描述在多個用例中都有的公共行為。包含關(guān)系本質(zhì)上是比較特殊的依賴關(guān)系。它比一般的依賴關(guān)系多了一些語義。在包含關(guān)系中箭頭的方向是從基本用例到包含用例。在UML1.1中用例之間是使用和擴展這兩種關(guān)系，這兩種關(guān)系都是泛化關(guān)系的版型。在UML1.3以后的版本中用例之間是包含和擴展這兩種關(guān)系。 l 泛化關(guān)系：它的意思和面向?qū)ο蟪绦蛟O(shè)計中的繼承的概念是類似的。不同的是繼承使用在實施階段，泛化使用在分析、設(shè)計階段。在泛化關(guān)系中子用例繼承了父用例的行為和含義，子用例也可以增加新的行為和含義或者覆蓋父用例中的行為和含義。 l

5、 擴展關(guān)系擴展關(guān)系的基本含義和泛化關(guān)系類似，但在擴展關(guān)系中，對于擴展用例有更多的規(guī)則限制，基本用例必須聲明擴展點，而擴展用例只能在擴展點上增加新的行為和含義。與包含關(guān)系一樣，擴展關(guān)系也是依賴關(guān)系的版型。在擴展關(guān)系中，箭頭的方向是從擴展用例到基本用例，這與包含關(guān)系是不同的。 用例的泛化、包含、擴展關(guān)系的比較。一般來說可以使用“is a”和“has a”來判斷使用那種關(guān)系。泛化和擴展關(guān)系表示用例之間是“is a”關(guān)系，包含關(guān)系表示用例之間是“has a”關(guān)系。擴展與泛化相比多了擴展點，擴展用例只能在基本用例的擴展點上進行擴展。在擴展關(guān)系中基本用例是獨立存在。在包含關(guān)系中執(zhí)行基本用例的時候一定會執(zhí)行

6、包含用例。（1）如果需要重復(fù)處理兩個或多個用例時可以考慮使用包含關(guān)系，實現(xiàn)一個基本用例對另一個的引用。（2）當處理正常行為的變形是偶爾描述時可以考慮只用泛化關(guān)系。（3）當描述正常行為的變形希望采用更多的控制方式時，可以在基本用例中設(shè)置擴展點，使用擴展關(guān)系。擴展關(guān)系比較難理解，如果把擴展關(guān)系看作是帶有更多規(guī)則限制的泛化關(guān)系，可以幫助理解。通常先獲得基本用例，針對這個用例中的每一個行為提問：該步驟會出什么差錯？該步驟有不同的情況嗎？該步驟的工作怎樣以不同的方式進行等，把所有的變化情況都標識為擴展。通?；居美苋菀讟?gòu)造，而擴展用例需要反復(fù)分析、驗證。當我們發(fā)現(xiàn)已經(jīng)存在的兩個用例間具有某種相似性時，

7、可以把相似的部分從兩個用例中抽象出來單獨作為一個用例，該用例被這兩個用例同時使用，這個抽象出的用例和另外兩個用例形成包含關(guān)系。 用例之間的關(guān)系舉例：包含：業(yè)務(wù)中，總是存在著維護某某信息的功能，如果將它作為一個用例，那新建、編輯以及修改都要在用例詳述中描述，過于復(fù)雜；如果分成新建用例、編輯用例和刪除用例，則劃分太細。這時包含關(guān)系可以用來理清關(guān)系。 擴展：系統(tǒng)中允許用戶對查詢的結(jié)果進行導(dǎo)出、打印。對于查詢而言，能不能導(dǎo)出、打印查詢都是一樣的，導(dǎo)出、打印是不可見的。導(dǎo)入、打印和查詢相對獨立，而且為查詢添加了新行為。 泛化：子用例將繼承父用例的所有結(jié)構(gòu)、行為和關(guān)系。子用例可以使用父用例的一段行為，也可

8、以重載它。父用例通常是抽象的。4、 畫法例子二、 類圖1、 定義類圖Class diagram通過顯示出系統(tǒng)的類以及這些類之間的關(guān)系來表示系統(tǒng)。類圖是靜態(tài)的它們顯示出什么可以產(chǎn)生影響但不會告訴你什么時候產(chǎn)生影響。在系統(tǒng)分析階段將類分成三種類型：實體類、邊界類、控制類 邊界類用于描述外部參與者與系統(tǒng)之間的交互。識別邊界類可以幫助開發(fā)人員識別出用戶對界面的需求。實體類主要是作為數(shù)據(jù)管理和業(yè)務(wù)邏輯處理層面上存在的類別； 它們主要在分析階段區(qū)分。 實體類的主要職責是存儲和管理系統(tǒng)內(nèi)部的信息，它也可以有行為，甚至很復(fù)雜的行為，但這些行為必須與它所代表的實體對象密切相關(guān)?？刂祁愑糜诿枋鲆粋€用例所具有的事件

9、流控制行為，控制一個用例中的事件順序。2、 用途類圖的目的是顯示建模系統(tǒng)的類型，描述組成系統(tǒng)的對象內(nèi)容與對象之間的關(guān)系。3、 組成元素以及元素之間的關(guān)系說明類名類的 UML 表示是一個長方形，垂直地分為三個區(qū)，如圖 1 所示。頂部區(qū)域顯示類的名字。中間的區(qū)域列出類的屬性。底部的區(qū)域列出類的操作。當在一個類圖上畫一個類元素時，你必須要有頂端的區(qū)域，下面的二個區(qū)域是可選擇的（當圖描述僅僅用于顯示分類器間關(guān)系的高層細節(jié)時，下面的兩個區(qū)域是不必要的）。圖 1 顯示一個航線班機如何作為 UML 類建模。正如我們所能見到的，名字是 Flight，我們可以在中間區(qū)域看到Flight類的3個屬性：flight

10、Number，departureTime 和 flightDuration。在底部區(qū)域中我們可以看到Flight類有兩個操作：delayFlight 和 getArrivalTime。圖 1: Flight類的類圖類屬性列表類的屬性節(jié)（中部區(qū)域）在分隔線上列出每一個類的屬性。屬性節(jié)是可選擇的，要是一用它，就包含類的列表顯示的每個屬性。 如下格式：name : attribute typeflightNumber : Integer繼續(xù)我們的Flight類的例子，我們可以使用屬性類型信息來描述類的屬性，如表 1 所示。表 1：具有關(guān)聯(lián)類型的Flight類的屬性名字屬性名稱屬性類型flightNu

11、mberIntegerdepartureTimeDateflightDurationMinutes在業(yè)務(wù)類圖中，屬性類型通常與單位相符，這對于圖的可能讀者是有意義的（例如，分鐘，美元，等等）。然而，用于生成代碼的類圖，要求類的屬性類型必須限制在由程序語言提供的類型之中，或包含于在系統(tǒng)中實現(xiàn)的、模型的類型之中。在類圖上顯示具有默認值的特定屬性，有時是有用的（例如，在銀行賬戶應(yīng)用程序中，一個新的銀行賬戶會以零為初始值）。UML 規(guī)范允許在屬性列表節(jié)中，通過使用如下的記號作為默認值的標識：name : attribute type = default value舉例來說：balance : Doll

12、ars = 0顯示屬性默認值是可選擇的；圖 2 顯示一個銀行賬戶類具有一個名為 balance的類型，它的默認值為0。圖 2：顯示默認為0美元的balance屬性值的銀行賬戶類圖。類操作列表類操作記錄在類圖長方形的第三個（最低的）區(qū)域中，它也是可選擇的。和屬性一樣，類的操作以列表格式顯示，每個操作在它自己線上。操作使用下列記號表現(xiàn)：name(parameter list) : type of value returned圖3顯示，delayFlight 操作有一個Minutes類型的輸入?yún)?shù) - numberOfMinutes。然而，delayFlight 操作沒有返回值。1當一個操作有參數(shù)時

13、，參數(shù)被放在操作的括號內(nèi)；每個參數(shù)都使用這樣的格式：“參數(shù)名：參數(shù)類型”。圖 3：Flight類操作參數(shù)，包括可選擇的“in”標識。當文檔化操作參數(shù)時，你可能使用一個可選擇的指示器，以顯示參數(shù)到操作的輸入?yún)?shù)、或輸出參數(shù)。這個可選擇的指示器以“in”或“out”出現(xiàn)，如圖3中的操作區(qū)域所示。一般來說，除非將使用一種早期的程序編程語言，如Fortran ，這些指示器可能會有所幫助，否則它們是不必要的。然而，在 C+和Java中，所有的參數(shù)是“in”參數(shù)，而且按照UML規(guī)范，既然“in”是參數(shù)的默認類型，大多數(shù)人將會遺漏輸入/輸出指示器。繼承在面向?qū)ο蟮脑O(shè)計中一個非常重要的概念，繼承，指的是一個類

14、（子類）繼承另外的一個類（超類）的同一功能，并增加它自己的新功能（一個非技術(shù)性的比喻，想象我繼承了我母親的一般的音樂能力，但是在我的家里，我是唯一一個玩電吉他的人）的能力。為了在一個類圖上建模繼承，從子類（要繼承行為的類）拉出一條閉合的，單鍵頭（或三角形）的實線指向超類。考慮銀行賬戶的類型：圖 4 顯示 CheckingAccount 和 SavingsAccount 類如何從 BankAccount 類繼承而來。圖 4: 繼承通過指向超類的一條閉合的，單箭頭的實線表示。在圖 4 中，繼承關(guān)系由每個超類的單獨的線畫出，這是在IBM Rational Rose和IBM Rational XDE中

15、使用的方法。然而，有一種稱為 樹標記的備選方法可以畫出繼承關(guān)系。當存在兩個或更多子類時，如圖 4 中所示，除了繼承線象樹枝一樣混在一起外，你可以使用樹形記號。圖 5 是重繪的與圖 4 一樣的繼承，但是這次使用了樹形記號。圖 5: 一個使用樹形記號的繼承實例抽象類及操作細心的讀者會注意到，在圖 4 和 圖5 中的圖中,類名BankAccount和withdrawal操作使用斜體。這表示，BankAccount 類是一個抽象類，而withdrawal方法是抽象的操作。換句話說，BankAccount 類使用withdrawal規(guī)定抽象操作，并且CheckingAccount 和 SavingsAc

16、count 兩個子類都分別地執(zhí)行它們各自版本的操作。然而，超類（父類）不一定要是抽象類。標準類作為超類是正常的。關(guān)聯(lián)當你系統(tǒng)建模時，特定的對象間將會彼此關(guān)聯(lián)，而且這些關(guān)聯(lián)本身需要被清晰地建模。有五種關(guān)聯(lián)。在這一部分中，我將會討論它們中的兩個 - 雙向的關(guān)聯(lián)和單向的關(guān)聯(lián)，而且我將會在Beyond the basics部分討論剩下的三種關(guān)聯(lián)類型。請注意，關(guān)于何時該使用每種類型關(guān)聯(lián)的詳細討論，不屬于本文的范圍。相反的，我將會把重點集中在每種關(guān)聯(lián)的用途，并說明如何在類圖上畫出關(guān)聯(lián)。雙向（標準）的關(guān)聯(lián)關(guān)聯(lián)是兩個類間的聯(lián)接。關(guān)聯(lián)總是被假定是雙向的；這意味著，兩個類彼此知道它們間的聯(lián)系，除非你限定一些其它類

17、型的關(guān)聯(lián)?；仡櫼幌翭light 的例子，圖 6 顯示了在Flight類和Plane類之間的一個標準類型的關(guān)聯(lián)。圖 6：在一個Flight類和Plane類之間的雙向關(guān)聯(lián)的實例一個雙向關(guān)聯(lián)用兩個類間的實線表示。在線的任一端，你放置一個角色名和多重值。圖 6 顯示Flight與一個特定的Plane相關(guān)聯(lián)，而且Flight類知道這個關(guān)聯(lián)。因為角色名以Plane類表示，所以Plane承擔關(guān)聯(lián)中的“assignedPlane”角色。緊接于Plane類后面的多重值描述0.1表示，當一個Flight實體存在時，可以有一個或沒有Plane與之關(guān)聯(lián)（也就是，Plane可能還沒有被分配）。圖 6 也顯示Plane知

18、道它與Flight類的關(guān)聯(lián)。在這個關(guān)聯(lián)中，F(xiàn)light承擔“assignedFlights”角色；圖 6 的圖告訴我們，Plane實體可以不與flight關(guān)聯(lián)（例如，它是一架全新的飛機）或與沒有上限的flight（例如，一架已經(jīng)服役5年的飛機）關(guān)聯(lián)。由于對那些在關(guān)聯(lián)尾部可能出現(xiàn)的多重值描述感到疑惑，下面的表3列出了一些多重值及它們含義的例子。表 3: 多重值和它們的表示表示含義0.1 0個或1個1只能1個0.*0個或多個* 0個或多個1.*1個或多個3只能3個0.50到5個5.15 5到15個單向關(guān)聯(lián)在一個單向關(guān)聯(lián)中，兩個類是相關(guān)的，但是只有一個類知道這種聯(lián)系的存在。圖 7 顯示單向關(guān)聯(lián)的透支

19、財務(wù)報告的一個實例。圖 7: 單向關(guān)聯(lián)一個實例：OverdrawnAccountsReport 類 BankAccount 類，而 BankAccount 類則對關(guān)聯(lián)一無所知。一個單向的關(guān)聯(lián)，表示為一條帶有指向已知類的開放箭頭（不關(guān)閉的箭頭或三角形，用于標志繼承）的實線。如同標準關(guān)聯(lián)，單向關(guān)聯(lián)包括一個角色名和一個多重值描述，但是與標準的雙向關(guān)聯(lián)不同的時，單向關(guān)聯(lián)只包含已知類的角色名和多重值描述。在圖 7 中的例子中，OverdrawnAccountsReport 知道 BankAccount 類，而且知道 BankAccount 類扮演“overdrawnAccounts”的角色。然而，和標準

20、關(guān)聯(lián)不同，BankAccount 類并不知道它與 OverdrawnAccountsReport 相關(guān)聯(lián)。2軟件包不可避免，如果你正在為一個大的系統(tǒng)或大的業(yè)務(wù)領(lǐng)域建模，在你的模型中將會有許多不同的分類器。管理所有的類將是一件令人生畏的任務(wù)；所以，UML 提供一個稱為 軟件包的組織元素。軟件包使建模者能夠組織模型分類器到名字空間中，這有些象文件系統(tǒng)中的文件夾。把一個系統(tǒng)分為多個軟件包使系統(tǒng)變成容易理解，尤其是在每個軟件包都表現(xiàn)系統(tǒng)的一個特定部分時。3在圖中存在兩種方法表示軟件包。并沒有規(guī)則要求使用哪種標記，除了用你個人的判斷：哪種更便于閱讀你畫的類圖。兩種方法都是由一個較小的長方形（用于定位）嵌

21、套在一個大的長方形中開始的，如圖 8 所示。但是建模者必須決定包的成員如何表示，如下： 如果建模者決定在大長方形中顯示軟件包的成員，則所有的那些成員4 需要被放置在長方形里面。另外，所有軟件包的名字需要放在軟件包的較小長方形之內(nèi)（如圖 8 的顯示）。 如果建模者決定在大的長方形之外顯示軟件包成員，則所有將會在圖上顯示的成員都需要被置于長方形之外。為了顯示屬于軟件包的分類器，從每個分類器畫一條線到里面有加號的圓周，這些圓周粘附在軟件包之上（圖9）。圖 8：在軟件包的長方形內(nèi)顯示軟件包成員的軟件包元素例子圖 9：一個通過連接線表現(xiàn)軟件包成員的軟件包例子在 UML 2 中，了解類圖的基礎(chǔ)更為重要。這

22、是因為類圖為所有的其他結(jié)構(gòu)圖提供基本的構(gòu)建塊。如組件或?qū)ο髨D（僅僅是舉了些例子）。在下面的部分中，會使用的類圖的更重要的方面。這些包括UML 2 規(guī)范中的接口，其它的三種關(guān)聯(lián)類型，可見性和其他補充。接口在本文的前面，我建議你以類來考慮分類器。事實上，分類器是一個更為一般的概念，它包括數(shù)據(jù)類型和接口。關(guān)于何時、以及如何高效地在系統(tǒng)結(jié)構(gòu)圖中使用數(shù)據(jù)類型和接口的完整討論，不在本文的討論范圍之內(nèi)。既然這樣，我為什么要在這里提及數(shù)據(jù)類型和接口呢？你可能想在結(jié)構(gòu)圖上模仿這些分類器類型，在這個時候，使用正確的記號來表示，或者至少知道這些分類器類型是重要的。不正確地繪制這些分類器，很有可能將使你的結(jié)構(gòu)圖讀者感

23、到混亂，以后的系統(tǒng)將不能適應(yīng)需求。一個類和一個接口不同：一個類可以有它形態(tài)的真實實例，然而一個接口必須至少有一個類來實現(xiàn)它。在 UML 2 中，一個接口被認為是類建模元素的特殊化。因此，接口就象類那樣繪制，但是長方形的頂部區(qū)域也有文本“interface”，如圖 10 所示。5圖 10：Professor類和Student類實現(xiàn)Person接口的類圖實例在圖 10 中顯示的圖中，Professor和Student類都實現(xiàn)了Person的接口，但并不從它繼承。我們知道這一點是由于下面兩個原因：1) Person對象作為接口被定義 - 它在對象的名字區(qū)域中有“interface”文本，而且我們看到

24、由于Professor和Student對象根據(jù)畫類對象的規(guī)則（在它們的名字區(qū)域中沒有額外的分類器文本）標示，所以它們是 類對象。 2) 我們知道繼承在這里沒有被顯示，因為與帶箭頭的線是點線而不是實線。如圖 10 所示，一條帶有閉合的單向箭頭的點 線意味著實現(xiàn)（或?qū)嵤?；正如我們在圖 4 中所見到的，一條帶有閉合單向箭頭的實線表示繼承。更多的關(guān)聯(lián)在上面，我討論了雙向關(guān)聯(lián)和單向關(guān)聯(lián)?，F(xiàn)在，我將會介紹剩下的三種類型的關(guān)聯(lián)。（1）關(guān)聯(lián)類在關(guān)聯(lián)建模中，存在一些情況下，你需要包括其它類，因為它包含了關(guān)于關(guān)聯(lián)的有價值的信息。對于這種情況，你會使用 關(guān)聯(lián)類 來綁定你的基本關(guān)聯(lián)。關(guān)聯(lián)類和一般類一樣表示。不同的是

25、，主類和關(guān)聯(lián)類之間用一條相交的點線連接。圖 11 顯示一個航空工業(yè)實例的關(guān)聯(lián)類。圖 11：增加關(guān)聯(lián)類 MileageCredit在圖 11 中顯示的類圖中，在Flight類和 FrequentFlyer 類之間的關(guān)聯(lián)，產(chǎn)生了稱為 MileageCredit的關(guān)聯(lián)類。這意味當Flight類的一個實例關(guān)聯(lián)到 FrequentFlyer 類的一個實例時，將會產(chǎn)生 MileageCredit 類的一個實例。（2）聚合聚合是一種特別類型的關(guān)聯(lián)，用于描述“總體到局部”的關(guān)系。在基本的聚合關(guān)系中， 部分類 的生命周期獨立于 整體類 的生命周期。舉例來說，我們可以想象，車 是一個整體實體，而 車輪 輪胎是整輛

26、車的一部分。輪胎可以在安置到車時的前幾個星期被制造，并放置于倉庫中。在這個實例中，Wheel類實例清楚地獨立地Car類實例而存在。然而，有些情況下， 部分 類的生命周期并 不 獨立于 整體 類的生命周期 - 這稱為合成聚合。舉例來說，考慮公司與部門的關(guān)系。 公司和部門 都建模成類，在公司存在之前，部門不能存在。這里Department類的實例依賴于Company類的實例而存在。讓我們更進一步探討基本聚合和組合聚合。l 基本聚合有聚合關(guān)系的關(guān)聯(lián)指出，某個類是另外某個類的一部分。在一個聚合關(guān)系中，子類實例可以比父類存在更長的時間。為了表現(xiàn)一個聚合關(guān)系，你畫一條從父類到部分類的實線，并在父類的關(guān)聯(lián)末

27、端畫一個未填充棱形。圖 12 顯示車和輪胎間的聚合關(guān)系的例子。圖 12: 一個聚合關(guān)聯(lián)的例子l 組合聚合組合聚合關(guān)系是聚合關(guān)系的另一種形式，但是子類實例的生命周期依賴于父類實例的生命周期。在圖13中，顯示了Company類和Department類之間的組合關(guān)系，注意組合關(guān)系如聚合關(guān)系一樣繪制，不過這次菱形是被填充的。圖 13: 一個組合關(guān)系的例子在圖 13 中的關(guān)系建模中，一個Company類實例至少總有一個Department類實例。因為關(guān)系是組合關(guān)系，當Company實例被移除/銷毀時，Department實例也將自動地被移除/銷毀。組合聚合的另一個重要功能是部分類只能與父類的實例相關(guān)（舉

28、例來說，我們例子中的Company類）。（3）反射關(guān)聯(lián)現(xiàn)在我們已經(jīng)討論了所有的關(guān)聯(lián)類型。就如你可能注意到的，我們的所有例子已經(jīng)顯示了兩個不同類之間的關(guān)系。然而，類也可以使用反射關(guān)聯(lián)與它本身相關(guān)聯(lián)。起先，這可能沒有意義，但是記住，類是抽象的。圖 14 顯示一個Employee類如何通過manager / manages角色與它本身相關(guān)。當一個類關(guān)聯(lián)到它本身時，這并不意味著類的實例與它本身相關(guān)，而是類的一個實例與類的另一個實例相關(guān)。圖 14：一個反射關(guān)聯(lián)關(guān)系的實例圖 14 描繪的關(guān)系說明一個Employee實例可能是另外一個Employee實例的經(jīng)理。然而，因為“manages”的關(guān)系角色有 0.

29、*的多重性描述；一個雇員可能不受任何其他雇員管理?？梢娦栽诿嫦?qū)ο蟮脑O(shè)計中，存在屬性及操作可見性的記號。UML 識別四種類型的可見性：public，protected，private及package。UML 規(guī)范并不要求屬性及操作可見性必須顯示在類圖上，但是它要求為每個屬性及操作定義可見性。為了在類圖上的顯示可見性，放置可見性標志于屬性或操作的名字之前。雖然 UML 指定四種可見性類型，但是實際的編程語言可能增加額外的可見性，或不支持 UML 定義的可見性。表4顯示了 UML 支持的可見性類型的不同標志。表 4：UML 支持的可見性類型的標志標志可見性類型+Public# Protected-

30、 PrivatePackage現(xiàn)在，讓我們看一個類，以說明屬性及操作的可見性類型。在圖 15 中，所有的屬性及操作都是public，除了 updateBalance 操作。updateBalance 操作是protected。圖 15：一個 BankAccount 類說明它的屬性及操作的可見性UML 2 補充既然我們已經(jīng)覆蓋了基礎(chǔ)和高級主題，我們將覆蓋一些由UML 1. x增加的類圖的新記號。（1）實例（具體對象）是一個具體的對象當一個系統(tǒng)結(jié)構(gòu)建模時，顯示例子類實例有時候是有用的。為了這種結(jié)構(gòu)建模，UML 2 提供 實例規(guī)范 元素，它顯示在系統(tǒng)中使用例子（或現(xiàn)實）實例的值得注意的信息。實例的記

31、號和類一樣，但是取代頂端區(qū)域中僅有的類名，它的名字是經(jīng)過拼接的:Instance Name : Class Name舉例來說（有下劃線）：Donald : Person因為顯示實例的目的是顯示值得注意的或相關(guān)的信息，沒必要在你的模型中包含整個實體屬性及操作。相反地，僅僅顯示感興趣的屬性及其值是完全恰當?shù)?。如圖16所描述。圖 16：Plane類的一個實例例子（只顯示感興趣的屬性值）然而，僅僅表現(xiàn)一些實例而沒有它們的關(guān)系不太實用；因此，UML 2 也允許在實體層的關(guān)系/關(guān)聯(lián)建模。繪制關(guān)聯(lián)與一般的類關(guān)系的規(guī)則一樣，除了在建模關(guān)聯(lián)時有一個附加的要求。附加的限制是，關(guān)聯(lián)關(guān)系必須與類圖的關(guān)系相一致，而且關(guān)

32、聯(lián)的角色名字也必須與類圖相一致。它的一個例子顯示于圖 17 中。在這個例子中，實例是圖 6 中類圖的例子實例。圖 17：圖 6 中用實例代替類的例子圖 17 有Flight類的二個實例，因為類圖指出了在Plane類和Flight類之間的關(guān)系是 0或多。因此，我們的例子給出了兩個與NX0337 Plane實例相關(guān)的Flight實例。（2）角色建模類的實例有時比期望的更為詳細。有時，你可能僅僅想要在一個較多的一般層次做類關(guān)系的模型。在這種情況下，你應(yīng)該使用 角色 記號。角色記號類似于實例記號。為了建立類的角色模型，你畫一個方格，并在內(nèi)部放置類的角色名及類名，作為實體記號，但是在這情況你不能加下劃線

33、。圖 18 顯示一個由圖 14 中圖描述的雇員類扮演的角色實例。在圖 18 中，我們可以認為，即使雇員類與它本身相關(guān)，關(guān)系確實是關(guān)于雇員之間扮演經(jīng)理及團隊成員的角色。圖 18：一個類圖顯示圖14中扮演不同角色的類注意：你不能在純粹類圖中做類角色的建模，即使圖 18顯示你可以這么做。為了使用角色記號，你將會需要使用下面討論的內(nèi)部結(jié)構(gòu)記號。（3）內(nèi)部的結(jié)構(gòu)UML 2 結(jié)構(gòu)圖的更有用的功能之一是新的內(nèi)部結(jié)構(gòu)記號。它允許你顯示一個類或另外的一個分類器如何在內(nèi)部構(gòu)成。這在 UML 1. x 中是不可能的，因為記號限制你只能顯示一個類所擁有的聚合關(guān)系?，F(xiàn)在，在 UML 2 中，內(nèi)部的結(jié)構(gòu)記號讓你更清楚地顯

34、示類的各個部分如何保持關(guān)系。讓我們看一個實例。在圖 18 中我們有一個類圖以表現(xiàn)一個Plane類如何由四個引擎和兩個控制軟件對象組成。從這個圖中省略的東西是顯示關(guān)于飛機部件如何被裝配的一些信息。從圖 18 無法說明，是每個控制軟件對象控制兩個引擎，還是一個控制軟件對象控制三個引擎，而另一個控制一個引擎。圖 18: 只顯示對象之間關(guān)系的類圖繪制類的內(nèi)在結(jié)構(gòu)將會改善這種狀態(tài)。開始時，你通過用二個區(qū)域畫一個方格。最頂端的區(qū)域包含類名字，而較低的區(qū)域包含類的內(nèi)部結(jié)構(gòu)，顯示在它們父類中承擔不同角色的部分類，角色中的每個部分類也關(guān)系到其它類。圖 19 顯示了Plane類的內(nèi)部結(jié)構(gòu)；注意內(nèi)部結(jié)構(gòu)如何澄清混亂

35、性。圖 20：Plane類的內(nèi)部結(jié)構(gòu)例子。在圖 20 中Plane有兩個 ControlSoftware 對象，而且每個控制二個引擎。在圖左邊上的 ControlSoftware（control1）控制引擎 1 和 2 。在圖右邊的 ControlSoftware（control2）控制引擎 3 和 4 。結(jié)論：至少存在兩個了解類圖的重要理由。第一個是它顯示系統(tǒng)分類器的靜態(tài)結(jié)構(gòu)；第二個理由是類圖為UML描述的其他結(jié)構(gòu)圖提供了基本記號。開發(fā)者將會認為類圖是為他們特別建立的；但是其他的團隊成員將發(fā)現(xiàn)它們也是有用的。業(yè)務(wù)分析師可以用類圖，為系統(tǒng)的業(yè)務(wù)遠景建模。4、 畫法例子三、 對象圖1、 定義對象

36、圖好像ROSE中沒有單獨說明。大概是覺得用途不大，類圖足夠表達了。對象圖(Object Diagram) 是顯示了一組對象和他們之間的關(guān)系。使用對象圖來說明數(shù)據(jù)結(jié)構(gòu)，類圖中的類或組件等的實例的靜態(tài)快照。對象圖和類圖一樣反映系統(tǒng)的靜態(tài)過程，但它是從實際的或原型化的情景來表達的。 對象圖是類圖的實例，幾乎使用與類圖完全相同的標識。他們的不同點在于對象圖顯示類的多個對象實例，而不是實際的類。一個對象圖是類圖的一個實例。由于對象存在生命周期，因此對象圖只能在系統(tǒng)某一時間段存在。 2、 用途對象圖顯示某時刻對象和對象之間的關(guān)系。一個對象圖可看成一個類圖的特殊用例，實例和類可在其中顯示。對象也和合作圖相聯(lián)

37、系，合作圖顯示處于語境中的對象原型（類元角色）。 對象圖的用途如下： 捕獲實例和連接 在分析和設(shè)計階段創(chuàng)建 捕獲交互的靜態(tài)部分 舉例說明數(shù)據(jù)/對象結(jié)構(gòu) 詳細描述瞬態(tài)圖 由分析人員、設(shè)計人員和代碼實現(xiàn)人員開發(fā) 3、 組成元素以及元素之間的關(guān)系說明表示法: 對于對象圖來說無需提供單獨的形式。類圖中就包含了對象，所以只有對象而無類的類圖就是一個對象圖。然而，對象圖這條短語在刻畫各方面特定使用時非常有用。對象圖顯示對象集及其聯(lián)系，代表了系統(tǒng)某時刻的狀態(tài)。它包含帶有值的對象，而非描述符，當然，在許多情況下對象可以是原型。用合作圖可顯示一個可多次實例化的對象及其聯(lián)系的總體模型，合作圖包含對象和鏈的描述符（

38、類元角色和聯(lián)系角色）。如果合作圖實例化，則產(chǎn)生了對象圖。 對象圖不顯示系統(tǒng)的演化過程。為此目的，可用帶消息的合作圖，或用順序圖表示一次交互。類圖與對象圖的區(qū)別：類圖對象圖在類中包含三部分，分別是類名、類的屬性和類的操作對象包含兩個部分：對象的名稱和對象的屬性類的名稱欄只包含類名對象的名稱欄包含“對象名：類名”類的屬性欄定義了所有屬性的特征對象的屬性欄定義了屬性的當前值類中列出了操作對象圖中不包含操作內(nèi)容，因為對屬于同一個類的對象，其操作是相同的類中使用了關(guān)聯(lián)連接，關(guān)聯(lián)中使用名稱、角色以及約束等特征定義對象使用鏈進行連接，鏈中包含名稱、角色類是一類對象的抽象，類不存在多重性對象可以具有多重性4、

39、 畫法例子四、 組件圖1、 定義我們可以使用組件圖來描述系統(tǒng)整體的分系統(tǒng)與子系統(tǒng)的關(guān)系構(gòu)成，因為從建模的觀點看，組件圖與子系統(tǒng)圖有時感到?jīng)]有區(qū)別。在 UML 1.1 中一個組件表現(xiàn)了實施項目，如文件和可運行的程序。不幸地，這與組件這個術(shù)語更為普遍的用法、指象COM組件這樣的東西相沖突。隨著時間的推移及UML的連續(xù)版本發(fā)布， UML 組件已經(jīng)失去了最初的絕大部分含義。UML 2 正式改變了組件概念的本質(zhì)意思；在 UML 2 中，組件被認為是獨立的，在一個系統(tǒng)或子系統(tǒng)中的封裝單位，提供一個或多個接口。雖然 UML 2 規(guī)范沒有嚴格地聲明它，但是組件是呈現(xiàn)事物的更大的設(shè)計單元，這些事物一般將使用可更

40、換的組件來實現(xiàn)。但是，并不象在 UML 1. x中，現(xiàn)在，組件必須有嚴格的邏輯，設(shè)計時構(gòu)造。主要思想是，你能容易地在你的設(shè)計中重用及/或替換一個不同的組件實現(xiàn)，因為一個組件封裝了行為，實現(xiàn)了特定接口（可以理解為將接口的定義與實現(xiàn)封裝在一起的明確使用范圍的組合）。2、 用途組件圖的主要目的是顯示系統(tǒng)組件間的結(jié)構(gòu)關(guān)系。在以組件為基礎(chǔ)的開發(fā)（CBD）中，組件圖為架構(gòu)師提供一個開始為解決方案建模的自然形式。組件圖允許一個架構(gòu)師驗證系統(tǒng)的必需功能是由組件實現(xiàn)的，這樣確保了最終系統(tǒng)將會被接受。除此之外，組件圖對于不同的小組是有用的交流工具。圖可以呈現(xiàn)給關(guān)鍵項目發(fā)起人及實現(xiàn)人員。通常，當組件圖將系統(tǒng)的實現(xiàn)人

41、員連接起來的時候，組件圖通?？梢允鬼椖堪l(fā)起人感到輕松，因為圖展示了對將要被建立的整個系統(tǒng)的早期理解。開發(fā)者發(fā)現(xiàn)組件圖是有用的，因為組件圖給他們提供了將要建立的系統(tǒng)的高層次的架構(gòu)視圖，這將幫助開發(fā)者開始建立實現(xiàn)的路標，并決定關(guān)于任務(wù)分配及（或）增進需求技能。系統(tǒng)管理員發(fā)現(xiàn)組件圖是有用的，因為他們可以獲得將運行于他們系統(tǒng)上的邏輯軟件組件的早期視圖。雖然系統(tǒng)管理員將無法從圖上確定物理設(shè)備或物理的可執(zhí)行程序，但是，他們?nèi)匀粴g迎組件圖，因為它較早地提供了關(guān)于組件及其關(guān)系的信息（這允許系統(tǒng)管理員輕松地計劃后面的工作）。3、 組成元素以及元素之間的關(guān)系說明組件符號（NOTATION）在現(xiàn)在，組件圖符號集使它

42、成為最容易畫的 UML 圖之一。圖 1 顯示了一個使用前 UML 1.4 符號的簡單的組件圖；這個例子顯示兩個組件之間的關(guān)系：一個使用了Inventory System組件的Order System組件。正如你所能見到的，在UML 1.4 中，用一個大方塊，并且在它的左邊有兩個凸出的小方塊，來表示組件。圖 1：這個簡單的組件圖使用 UML 1.4 符號顯示Order System的一般性依賴關(guān)系上述的 UML 1.4 符號在 UML 2 中仍然被支持。然而，UML 1.4 符號集在較大的系統(tǒng)中不能很好地調(diào)節(jié)。關(guān)于這一點的理由是，如同我們在這篇文章的其余部分將會見到一樣，UML 2 顯著地增強了

43、組件圖的符號集。在維持它易于理解的條件下，UML 2 符號能夠調(diào)節(jié)得更好，并且符號集也具有更多的信息。 讓我們依照 UML 2 規(guī)范一步步建立組件圖。（1）基礎(chǔ)：現(xiàn)在，在 UML 2 中畫一個組件很類似于在一個類圖上畫一個類。事實上，在 UML 2 中，一個組件僅僅是類概念的一個特殊版本。這意味著適用于類分類器的符號規(guī)則也適用于組件分類器。在 UML 2 中，一個組件被畫成堆積著可選擇小塊的一個立著的長方形。UML 2 中，組件的一個高層次的抽象視圖，可以用一個長方形建模，包括組件的名字和組件原型的文字和/或圖標。組件原型的文本是“component”，而組件原型圖標是在左邊有兩個凸出的小長方

44、形的一個大長方形（UML 1.4 中組件的符號元素）。圖 2 顯示，組件可以用UML 2規(guī)范中的三種不同方法表示。圖 2：畫組件名字區(qū)的不同方法當在圖上畫一個組件時，重要的是，你總要包括組件原型文本（在雙重尖括號中的那個component，如圖 2 所示）和/或圖標。理由呢？在 UML 中，沒有任何原型分類器的一個長方形被解釋為一個類組件。組件原型和/或圖標用來區(qū)別作為組件元素的長方形。為組件提供/要求接口建模在圖 2 中所畫的Order組件表現(xiàn)了所有有效的符號元素；然而，一個典型的組件圖包括更多的信息。一個組件元素可以在名字區(qū)下面附加額外的區(qū)。如前面所提到的，一個組件是提供一個或更多公共接口

45、的獨立單元。提供的接口代表了組件提供給它的用戶/客戶的服務(wù)的正式契約。圖 3 顯示了Order組件有第二個區(qū)，用來表示Order組件提供和要求的接口。2圖 3：這里額外的區(qū)顯示Order組件提供和要求的接口。在圖 3 中的Order組件例子中，組件提供了名為 OrderEntry 和 AccountPayable 的接口。此外，組件也要求另外一個組件提供Person接口。3組件接口建模的其它方法UML 2 也引入另外一種方法來顯示組件提供并要求的接口。這個方法是建立一個里面有組件名的大長方形，并在長方形的外面放置在 UML 2 規(guī)范中稱為接口符號的東西。這第二種方法在圖 4 中舉例說明。圖 4

46、: 一種可選擇的方法（與圖3相比）：使用接口符號顯示組件提供/要求的接口在這第二種方法中，在末端有一個完整的圓周的接口符號代表組件提供的接口 - “棒棒糖”是這個接口分類器實現(xiàn)關(guān)系符號的速記法。在末端只有半個圓的接口（又稱插座）符號代表組件要求的接口（在兩種情況下，接口的名字被放置在接口符號本身的附近）。即使圖 4 看起來與圖 3 有很大的不同，但兩個圖都提供了相同的信息 - 例如，Order組件提供兩個接口：OrderEntry 和 AccountPayable，而且Order組件 要求 Person接口。（2）組件關(guān)系的建模當表現(xiàn)組件與其它組件的關(guān)系時，棒棒糖和插座符號也必須包括一支依存箭

47、頭（如類圖中所用的）。在有棒棒糖和插座的組件圖上，注意，依存箭從強烈的（要求的）插座引出，并且它的箭頭指向供應(yīng)者的棒棒糖，如圖 5 所示。圖 5：顯示Order系統(tǒng)組件如何依賴于其他組件的組件圖圖 5 顯示，Order系統(tǒng)組件依賴于客戶資源庫和庫存系統(tǒng)組件。注意在圖 5 中復(fù)制出的接口名 CustomerLookup 和 ProductAccessor。 在這個例子中，這看起來可能是不必要的重復(fù)，不過符號確實允許在每個依賴于實現(xiàn)差別的組件中有不同的接口（和不同的名字）（舉例來說，一個組件提供一個較小的必需的接口子類）。（3） 子系統(tǒng)在 UML 2 中，子系統(tǒng)分類器是組件分類器的一個特別版本。因

48、為這一點，子系統(tǒng)符號元素象組件符號元素一樣繼承所有的組件符號集規(guī)則。唯一的差別是，一個子系統(tǒng)符號元素由subsystem關(guān)鍵字代替了component，如圖 6 所示。圖 6：子系統(tǒng)元素的一個例子UML 2 規(guī)范在如何區(qū)別子系統(tǒng)與組件方面相當含糊。從建模的觀點，規(guī)范并不認為組件與子系統(tǒng)有任何區(qū)別。與 UML 1. x 相比較，這個 UML 2 模型歧義是新的。但是有一個理由。在 UML 1. x 中，一個子系統(tǒng)被認為是一個組件包，而且這個組件包符號正對許多 UML 實踐者造成困惑；因此，UML 2中把子系統(tǒng)作為特殊的組件，因為這是最多的 UML 1. x 使用者了解它的方式。這一改變確實把模糊

49、引入圖中，但是這一模糊更多的是 UML 2 規(guī)范中對抗錯誤的一個現(xiàn)實反射。到這里，你可能正在抓著頭皮并感到疑惑，什么時候該用組件元素，什么時候又該用子系統(tǒng)元素。相當坦率地說，我沒有一個直接的答案給你。我可以告訴你，UML 2 規(guī)范中說，何時該使用組件或子系統(tǒng)決定于建模者的方法論。我個人很喜歡這個答案，因為它幫助確保UML與方法論相互獨立，這在軟件開發(fā)中將幫助保持它的普遍可使用。（4）超越基礎(chǔ)組件圖是比較容易理解的圖之一，因此沒有很多超越基礎(chǔ)的內(nèi)容。然而，有一個方面你可以認為是略微困難的。l 顯示組件的內(nèi)部結(jié)構(gòu)有時候顯示組件的內(nèi)部結(jié)構(gòu)是有意義的。在關(guān)于類圖的我的前面的文章中，我顯示了該如何為類的

50、內(nèi)部結(jié)構(gòu)建模；這里，當它由其他組件組成的時候，我將會關(guān)注如何為組件的內(nèi)部結(jié)構(gòu)建模。為了顯示組件的內(nèi)部結(jié)構(gòu)，你只需把組件畫得比平常大一些并在名字區(qū)內(nèi)放置內(nèi)部的部分。圖 7 顯示Store組件的內(nèi)部結(jié)構(gòu)。圖 7: 這個組件的內(nèi)部結(jié)構(gòu)由其他組件組成。使用在圖 7 中顯示的例子，Store組件提供了 OrderEntry 接口并要求Account接口。Store組件由三個組件組成：Order，Customer和Product組件。注意Store的 OrderEntry 和Account接口符號在組件的邊緣上為何有一個方塊。這一個方塊被稱為一個端口。單純感覺來說，端口提供一種方法，它顯示建模組件所 提供

51、/要求 的接口如何與它里面的部分相關(guān)聯(lián)。4通過使用端口，我們可以從外部實例中分離出Store組件的內(nèi)部部件。在圖 7 中，對于過程而言，OrderEntry 端口代表Order組件的 OrderEntry 接口。同時，內(nèi)部的Customer組件要求的Account接口被分配到Store組件的必需的Account端口。通過連接Account端口，Store組件內(nèi)部部件（例如Customer組件）可以有代表執(zhí)行端口接口的未知外部實體的本地特征。必需的Account接口將會由Store組件的外部組件實現(xiàn)。5在圖 7 中，你可能也注意到了，在內(nèi)部的組件之間的內(nèi)部連接與圖 5 中顯示的那些不同。這是因為

52、內(nèi)部結(jié)構(gòu)的這些描繪事實是嵌套在分類器（在我們的例子中是一個組件)里的協(xié)作圖，因為協(xié)作圖顯示分類器中的實體或角色。在內(nèi)部的組件之間建模的關(guān)系以 UML 稱為的一個組合連接器表示。一個組合連接器綁定一個組件 提供 的接口到另外的一個組件的 必需 接口。組合連接器用緊緊相連的棒棒糖和插座符號表示。以這種方式畫這些組合連接器使棒棒糖和插座成為很容易理解的符號。l 結(jié)論組件圖經(jīng)常是一個架構(gòu)師在項目的初期就建立的非常重要的圖。然而，組件圖的有用性跨越了系統(tǒng)的壽命。組件圖是無價的，因為它們模型化和文檔化了一個系統(tǒng)的架構(gòu)。因為組件圖文檔化了系統(tǒng)的架構(gòu)，開發(fā)者和系統(tǒng)可能的系統(tǒng)管理員會發(fā)現(xiàn)這一工作的關(guān)鍵產(chǎn)品有助于

53、他們理解系統(tǒng)。組件圖也視為軟件系統(tǒng)配置圖的輸入。 l 腳注在UML1.x 中稱為組件的實際項目，在 UML 2 中稱為產(chǎn)物。一個產(chǎn)物是一個物理單位，象一個文件，可運行的程序，腳本，數(shù)據(jù)庫等等。只有一種產(chǎn)物依賴于實際的節(jié)點；類和組件沒有“位置”。然而，一個產(chǎn)物可能顯示組件和其他的分類器（例如類）。一個單一的組件可能通過多重產(chǎn)物顯示，它們可能是在相同的或不同的節(jié)點上，因此，一個單一的組件可以間接地在多重節(jié)點上被實現(xiàn)。即使組件是獨立的單元，它們?nèi)匀豢赡芤蕾囉谄渌M件提供的服務(wù)。由于這一點，文檔化一個組件的必需接口是很有用的。圖3并不顯示Order組件完整的上下文。在一個真實的模型中，OrderEnt

54、ry，AccountPayable 和Person接口會呈現(xiàn)在系統(tǒng)的模型中。事實上，端口適用于任何類型的分類器（例如，一個類或者你的模型中可能會有的其他分類器）。為了使本文簡潔，我在組件分類器及它們的使用中提及端口。一般來說，當你畫一個端口和一個接口之間的依存關(guān)系時，依賴方（要求）的接口將會在運行時間內(nèi)處理所有的處理邏輯。然而，這并不是一種硬性的規(guī)定 - 對于周圍的組件使用自己的進程邏輯，而不是僅把進程委托給依賴接口，是完全可以接受的。4、 畫法例子五、 序列圖1、 定義序列圖描述對象之間發(fā)送消息的時間順序，顯示多個對象之間的動態(tài)協(xié)作。它可以表示用例的行為順序，當執(zhí)行一個用例行為時，圖中的每條

55、消息對應(yīng)了一個類操作或狀態(tài)機中引起轉(zhuǎn)換的觸發(fā)事件。2、 用途序列圖用于為使用方案的邏輯建模。使用方案恰如其名稱所揭示的那樣-描述使用系統(tǒng)的潛在方法。使用方案的邏輯可以是用例的一部分，可能是備選過程。它也可以是整個用例過程，例如由基本行動過程描述的邏輯，或者部分基本行動過程再加上一個或多個替代方案描述的邏輯。使用方案的邏輯也可以是幾個用例中包含的邏輯。例如，一個學(xué)生在大學(xué)入學(xué)后，立即參加了三個研習(xí)班。序列圖以可視方式為系統(tǒng)中邏輯的流程建模，能夠讓您記載和驗證邏輯，這通常用于分析和設(shè)計目的。3、 組成元素以及元素之間的關(guān)系說明（1）分類器橫貫該圖頂部的那些框表示的是分類器或它們的實例 -通常是用例

56、、對象、類或參與者（往往用長方形表示，但它們也可以是符號）。 因為既可以向?qū)ο蟀l(fā)送消息，又可以向類發(fā)送消息（對象通過調(diào)用操作來響應(yīng)消息，而類則通過調(diào)用靜態(tài)操作來響應(yīng)消息），所以有必要將它們都包括在序列圖中。另外，因為參與者在使用方案中發(fā)起操作并占據(jù)主動地位，因此也要將他們包括在序列圖中。對象的標簽具有標準UML 格式 name: ClassName，其中的 name是可選的。（在圖中沒有給出名稱的對象稱為匿名對象。）類標簽的格式為ClassName，而參與者名的格式為 Actor Name - 這些也都是 UML標準。（2）生命線從各個框垂下來的虛線稱為對象生命線，表示在對方案建模期間對象的生

57、命跨度。生命線上的細長框是方法調(diào)用框，表明正在由目標對象類執(zhí)行處理，以完成消息。方法調(diào)用框底部的X 是一種 UML 約定，表明對象已從內(nèi)存中除去，這通常是接收到原型為 的消息的結(jié)果。 （3）為消息建模消息以帶有標簽的箭頭表示。當消息的源和目標為對象或類時，標簽是響應(yīng)消息時所調(diào)用方法的簽名。不過，如果源或目標中有一方是人類參與者，那么消息就用描述正在交流的信息的簡要文本作為標簽。例如，:EnrollInSeminar對象向 Seminar 的實例發(fā)送消息isEligibleToEnroll(theStudent)。請注意我是如何同時包含方法名和參數(shù)名的（如果有參數(shù)名，則傳遞給它）。 示例中表明 Student 參與者通過標簽為 name（“姓名”）和stud