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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17、型的關(guān)聯(lián)。回顧一下Flight 的例子，圖 6 顯示了在Flight類(lèi)和Plane類(lèi)之間的一個(gè)標(biāo)準(zhǔn)類(lèi)型的關(guān)聯(lián)。圖 6：在一個(gè)Flight類(lèi)和Plane類(lèi)之間的雙向關(guān)聯(lián)的實(shí)例一個(gè)雙向關(guān)聯(lián)用兩個(gè)類(lèi)間的實(shí)線(xiàn)表示。在線(xiàn)的任一端，你放置一個(gè)角色名和多重值。圖 6 顯示Flight與一個(gè)特定的Plane相關(guān)聯(lián)，而且Flight類(lèi)知道這個(gè)關(guān)聯(lián)。因?yàn)榻巧訮lane類(lèi)表示，所以Plane承擔(dān)關(guān)聯(lián)中的“assignedPlane”角色。緊接于Plane類(lèi)后面的多重值描述0.1表示，當(dāng)一個(gè)Flight實(shí)體存在時(shí)，可以有一個(gè)或沒(méi)有Plane與之關(guān)聯(lián)（也就是，Plane可能還沒(méi)有被分配）。圖 6 也顯示Plane知

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

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

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

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

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

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

24、由于Professor和Student對(duì)象根據(jù)畫(huà)類(lèi)對(duì)象的規(guī)則（在它們的名字區(qū)域中沒(méi)有額外的分類(lèi)器文本）標(biāo)示，所以它們是 類(lèi)對(duì)象。 2) 我們知道繼承在這里沒(méi)有被顯示，因?yàn)榕c帶箭頭的線(xiàn)是點(diǎn)線(xiàn)而不是實(shí)線(xiàn)。如圖 10 所示，一條帶有閉合的單向箭頭的點(diǎn) 線(xiàn)意味著實(shí)現(xiàn)（或?qū)嵤徽缥覀冊(cè)趫D 4 中所見(jiàn)到的，一條帶有閉合單向箭頭的實(shí)線(xiàn)表示繼承。更多的關(guān)聯(lián)在上面，我討論了雙向關(guān)聯(lián)和單向關(guān)聯(lián)?，F(xiàn)在，我將會(huì)介紹剩下的三種類(lèi)型的關(guān)聯(lián)。（1）關(guān)聯(lián)類(lèi)在關(guān)聯(lián)建模中，存在一些情況下，你需要包括其它類(lèi)，因?yàn)樗岁P(guān)于關(guān)聯(lián)的有價(jià)值的信息。對(duì)于這種情況，你會(huì)使用 關(guān)聯(lián)類(lèi) 來(lái)綁定你的基本關(guān)聯(lián)。關(guān)聯(lián)類(lèi)和一般類(lèi)一樣表示。不同的是

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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