| 雙向(標(biāo)準(zhǔn))的關(guān)聯(lián)  
 一 個(gè)雙向關(guān)聯(lián)用兩個(gè)類間的實(shí)線表示。在線的任一端,你放置一個(gè)角色名和多重值。圖 6 顯示Flight與一個(gè)特定的Plane相關(guān)聯(lián),而且Flight類知道這個(gè)關(guān)聯(lián)。因?yàn)榻巧訮lane類表示,所以Plane承擔(dān)關(guān)聯(lián)中的 “assignedPlane”角色。緊接于Plane類后面的多重值描述0...1表示,當(dāng)一個(gè)Flight實(shí)體存在時(shí),可以有一個(gè)或沒有Plane與 之關(guān)聯(lián)(也就是,Plane可能還沒有被分配)。圖 6 也顯示Plane知道它與Flight類的關(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ī))或與沒有上限的flight(例如,一架已經(jīng)服役5年的飛機(jī))關(guān)聯(lián)。 由于對(duì)那些在關(guān)聯(lián)尾部可能出現(xiàn)的多重值描述感到疑惑,下面的表3列出了一些多重值及它們含義的例子。 表 3: 多重值和它們的表示 
 單向關(guān)聯(lián) 在一個(gè)單向關(guān)聯(lián)中,兩個(gè)類是相關(guān)的,但是只有一個(gè)類知道這種聯(lián)系的存在。圖 7 顯示單向關(guān)聯(lián)的透支財(cái)務(wù)報(bào)告的一個(gè)實(shí)例。 
 一 個(gè)單向的關(guān)聯(lián),表示為一條帶有指向已知類的開放箭頭(不關(guān)閉的箭頭或三角形,用于標(biāo)志繼承)的實(shí)線。如同標(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)只包含已知類的角色名和多重值描述。在圖 7 中的例子中,OverdrawnAccountsReport 知道 BankAccount 類,而且知道 BankAccount 類扮演“overdrawnAccounts”的角色。然而,和標(biāo)準(zhǔn)關(guān)聯(lián)不同,BankAccount 類并不知道它與 OverdrawnAccountsReport 相關(guān)聯(lián)。2 軟件包  在圖中存在兩種方法表示軟件包。并沒有規(guī)則要求使用哪種標(biāo)記,除了用你個(gè)人的判斷:哪種更便于閱讀你畫的類圖。兩種方法都是由一個(gè)較小的長方形(用于定位)嵌套在一個(gè)大的長方形中開始的,如圖 8 所示。但是建模者必須決定包的成員如何表示,如下: 
 
 
 了解基礎(chǔ)重要性 在 UML 2 中,了解類圖的基礎(chǔ)更為重要。這是因?yàn)轭悎D為所有的其他結(jié)構(gòu)圖提供基本的構(gòu)建塊。如組件或?qū)ο髨D(僅僅是舉了些例子)。 超過基礎(chǔ) 接口  關(guān) 于何時(shí)、以及如何高效地在系統(tǒng)結(jié)構(gòu)圖中使用數(shù)據(jù)類型和接口的完整討論,不在本文的討論范圍之內(nèi)。既然這樣,我為什么要在這里提及數(shù)據(jù)類型和接口呢?你可能 想在結(jié)構(gòu)圖上模仿這些分類器類型,在這個(gè)時(shí)候,使用正確的記號(hào)來表示,或者至少知道這些分類器類型是重要的。不正確地繪制這些分類器,很有可能將使你的結(jié) 構(gòu)圖讀者感到混亂,以后的系統(tǒng)將不能適應(yīng)需求。 一個(gè)類和一個(gè)接口不同:一個(gè)類可以有它形態(tài)的真實(shí)實(shí)例,然而一個(gè)接口必須至少有一個(gè)類來實(shí)現(xiàn)它。在 UML 2 中,一個(gè)接口被認(rèn)為是類建模元素的特殊化。因此,接口就象類那樣繪制,但是長方形的頂部區(qū)域也有文本“interface”,如圖 10 所示5 
 在 圖 10 中顯示的圖中,Professor和Student類都實(shí)現(xiàn)了Person的接口,但并不從它繼承。我們知道這一點(diǎn)是由于下面兩個(gè)原因:1) Person對(duì)象作為接口被定義 -- 它在對(duì)象的名字區(qū)域中有“interface”文本,而且我們看到由于Professor和Student對(duì)象根據(jù)畫類對(duì)象的規(guī)則(在它們的名字區(qū)域中沒 有額外的分類器文本)標(biāo)示,所以它們是 類對(duì)象。 2) 我們知道繼承在這里沒有被顯示,因?yàn)榕c帶箭頭的線是點(diǎn)線而不是實(shí)線。如圖 10 所示,一條帶有閉合的單向箭頭的點(diǎn) 線意味著實(shí)現(xiàn)(或?qū)嵤徽缥覀冊(cè)趫D 4 中所見到的,一條帶有閉合單向箭頭的實(shí)線表示繼承。 更多的關(guān)聯(lián)  關(guān)聯(lián)類  
 在 圖 11 中顯示的類圖中,在Flight類和 FrequentFlyer 類之間的關(guān)聯(lián),產(chǎn)生了稱為 MileageCredit的關(guān)聯(lián)類。這意味當(dāng)Flight類的一個(gè)實(shí)例關(guān)聯(lián)到 FrequentFlyer 類的一個(gè)實(shí)例時(shí),將會(huì)產(chǎn)生 MileageCredit 類的一個(gè)實(shí)例。 聚合  舉 例來說,我們可以想象,車 是一個(gè)整體實(shí)體,而 車輪輪胎是整輛車的一部分。輪胎可以在安置到車時(shí)的前幾個(gè)星期被制造,并放置于倉庫中。在這個(gè)實(shí)例中,Wheel類實(shí)例清楚地獨(dú)立地Car類實(shí)例而存在。 然而,有些情況下, 部分 類的生命周期并 不 獨(dú)立于 整體 類的生命周期 -- 這稱為合成聚合。舉例來說,考慮公司與部門的關(guān)系。 公司和部門都建模成類,在公司存在之前,部門不能存在。這里Department類的實(shí)例依賴于Company類的實(shí)例而存在。 讓我們更進(jìn)一步探討基本聚合和組合聚合。 基本聚合  
 組合聚合  
 在 圖 13 中的關(guān)系建模中,一個(gè)Company類實(shí)例至少總有一個(gè)Department類實(shí)例。因?yàn)殛P(guān)系是組合關(guān)系,當(dāng)Company實(shí)例被移除/銷毀 時(shí),Department實(shí)例也將自動(dòng)地被移除/銷毀。組合聚合的另一個(gè)重要功能是部分類只能與父類的實(shí)例相關(guān)(舉例來說,我們例子中的Company 類)。 反射關(guān)聯(lián)  
 圖14:描繪的關(guān)系說明一個(gè)Employee實(shí)例可能是另外一個(gè)Employee實(shí)例的經(jīng)理。然而,因?yàn)椤癿anages”的關(guān)系角色有%200..*的多重性描述;一個(gè)雇員可能不受任何其他雇員管理。 可見性  UML 規(guī)范并不要求屬性及操作可見性必須顯示在類圖上,但是它要求為每個(gè)屬性及操作定義可見性。為了在類圖上的顯示可見性,放置可見性標(biāo)志于屬性或操作的名字之 前。雖然UML指定四種可見性類型,但是實(shí)際的編程語言可能增加額外的可見性,或不支持%20UML%20定義的可見性。表4顯示了UML支持的可見性類 型的不同標(biāo)志。 表4:UML支持的可見性類型的標(biāo)志 
 現(xiàn)在,讓我們看一個(gè)類,以說明屬性及操作的可見性類型。在圖 15 中,所有的屬性及操作都是public,除了 updateBalance 操作。updateBalance 操作是protected。 
 UML 2 補(bǔ)充  實(shí)例  實(shí)例的記號(hào)和類一樣,但是取代頂端區(qū)域中僅有的類名,它的名字是經(jīng)過拼接的: 
 舉例來說: 
 因?yàn)轱@示實(shí)例的目的是顯示值得注意的或相關(guān)的信息,沒必要在你的模型中包含整個(gè)實(shí)體屬性及操作。相反地,僅僅顯示感興趣的屬性及其值是完全恰當(dāng)?shù)?。如圖16所描述。 
 然 而,僅僅表現(xiàn)一些實(shí)例而沒有它們的關(guān)系不太實(shí)用;因此,UML 2 也允許在實(shí)體層的關(guān)系/關(guān)聯(lián)建模。繪制關(guān)聯(lián)與一般的類關(guān)系的規(guī)則一樣,除了在建模關(guān)聯(lián)時(shí)有一個(gè)附加的要求。附加的限制是,關(guān)聯(lián)關(guān)系必須與類圖的關(guān)系相一 致,而且關(guān)聯(lián)的角色名字也必須與類圖相一致。它的一個(gè)例子顯示于圖 17 中。在這個(gè)例子中,實(shí)例是圖 6 中類圖的例子實(shí)例。 
 圖 17 有Flight類的二個(gè)實(shí)例,因?yàn)轭悎D指出了在Plane類和Flight類之間的關(guān)系是 0或多。因此,我們的例子給出了兩個(gè)與NX0337 Plane實(shí)例相關(guān)的Flight實(shí)例。 角色  
 注意,你不能在純粹類圖中做類角色的建模,即使圖 18顯示你可以這么做。為了使用角色記號(hào),你將會(huì)需要使用下面討論的內(nèi)部結(jié)構(gòu)記號(hào)。 內(nèi)部的結(jié)構(gòu)  讓 我們看一個(gè)實(shí)例。在圖 18 中我們有一個(gè)類圖以表現(xiàn)一個(gè)Plane類如何由四個(gè)引擎和兩個(gè)控制軟件對(duì)象組成。從這個(gè)圖中省略的東西是顯示關(guān)于飛機(jī)部件如何被裝配的一些信息。從圖 18 的圖,你無法說明,是每個(gè)控制軟件對(duì)象控制兩個(gè)引擎,還是一個(gè)控制軟件對(duì)象控制三個(gè)引擎,而另一個(gè)控制一個(gè)引擎。 
 繪制類的內(nèi)在結(jié)構(gòu)將會(huì)改善這種狀態(tài)。開始時(shí),你通過用二個(gè)區(qū)域畫一個(gè)方格。最頂端的區(qū)域包含類名字,而較低的區(qū)域包含類的內(nèi)部結(jié)構(gòu),顯示在它們父類中承擔(dān)不同角色的部分類,角色中的每個(gè)部分類也關(guān)系到 | |||||||||||||||||||||||||||||||||
|  |