UML 基礎:類圖 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
http://Tech.acnow.net 2005-9-3 11:41:00 互連網 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
這是關於統一建模語言、即UML 裏採用的基本圖的一系列文章的一部分。在我 先前關於序列圖的文章 裏,我把重點從 UML 1.4 版,轉移到 OMG的採用UML 2.0版草案規範(又稱爲UML 2)。在這篇文章中,我將會討論結構圖,這是已經在 UML 2 中提出的一種新圖種類。由於本系列文章的目的是使人們瞭解記號元素及它們的含意,該文主要關注類圖。你很快就會知道這樣做的理由。隨後的文章將會覆蓋結構範疇中包含的其它圖。
我也想提醒讀者,這一系列文章是關於 UML 記號元素的,所以這些文章並不意味着爲建模的最好方式提供指導方針,或是該如何決定哪些內容應該首先被建模。相反的,該文及本系列文章的目的主要是幫助大家對於記號元素 -- 語法和含義有一個基本的理解。藉由這些知識,你應該可以閱讀圖,並使用正確的記號元素創建你自己的圖。 這篇文章假定你對面向對象的設計已經有了基本的理解。你們當中如果有人需要一些面向對象概念的幫助,那麼可以訪問http://java.sun.com/docs/books/tutorial/java/concepts/,來獲得Sun公司關於面向對象編程的簡短指導。閱讀 “什麼是類?”和 什麼是繼承?” 章節,將提供給你足夠的理解,並對該文的閱讀會有所幫助。另外,David Taylor的書《 Object-Oriented Technologies: A Manager's Guide》提供了面向對象設計的優秀,高水平的說明,而無需對計算機編程有高深的理解。 UML 2 中的陰和陽 大體上的結構圖 貫穿整個軟件生命週期,結構圖對於各種團隊成員都是有用的。一般而言,這些圖支持設計驗證,和個體與團隊間的設計交流。舉例來說,業務分析師可以使用類或對象圖,來爲當前的資產和資源建模,例如分類賬,產品或地理層次。架構師可以使用組件和部署圖,來測試/確認他們的設計是否充分。開發者可以使用類圖,來設計併爲系統的代碼(或即將成爲代碼的)類寫文檔。 特殊的類圖UML 2 把結構圖看成一個分類;這裏並不存在稱爲“結構圖”的圖。然而,類圖提供結構圖類型的一個主要實例,併爲我們提供一組記號元素的初始集,供所有其它結構圖使用。由於類圖是如此基本,本文的剩餘部分將會把重點集中在類圖記號集。在本文的結尾,你將對於如何畫UML 2類圖有所瞭解,而且對於理解在後面文章中將涉及的其他結構圖有一個穩固的基礎。 基礎
UML 爲這些類型起了一個特別的名字:“分類器”。通常地,你可以把分類器當做類,但在技術上,分類器是更爲普遍的術語,它還是引用上面的其它三種類型爲好。 類名 類的 UML 表示是一個長方形,垂直地分爲三個區,如圖 1 所示。頂部區域顯示類的名字。中間的區域列出類的屬性。底部的區域列出類的操作。當在一個類圖上畫一個類元素時,你必須要有頂端的區域,下面的二個區域是可選擇的(當圖描述僅僅用於顯示分類器間關係的高層細節時,下面的兩個區域是不必要的)。圖 1 顯示一個航線班機如何作爲 UML 類建模。正如我們所能見到的,名字是 Flight,我們可以在中間區域看到Flight類的3個屬性:flightNumber,departureTime 和 flightDuration。在底部區域中我們可以看到Flight類有兩個操作:delayFlight 和 getArrivalTime。 圖 1: Flight類的類圖
類屬性列表 類的屬性節(中部區域)在分隔線上列出每一個類的屬性。屬性節是可選擇的,要是一用它,就包含類的列表顯示的每個屬性。該線用如下格式:
繼續我們的Flight類的例子,我們可以使用屬性類型信息來描述類的屬性,如表 1 所示。 表 1:具有關聯類型的Flight類的屬性名字
在業務類圖中,屬性類型通常與單位相符,這對於圖的可能讀者是有意義的(例如,分鐘,美元,等等)。然而,用於生成代碼的類圖,要求類的屬性類型必須限制在由程序語言提供的類型之中,或包含於在系統中實現的、模型的類型之中。 在類圖上顯示具有默認值的特定屬性,有時是有用的(例如,在銀行賬戶應用程序中,一個新的銀行賬戶會以零爲初始值)。UML 規範允許在屬性列表節中,通過使用如下的記號作爲默認值的標識:
舉例來說:
顯示屬性默認值是可選擇的;圖 2 顯示一個銀行賬戶類具有一個名爲 balance的類型,它的默認值爲0。 圖 2:顯示默認爲0美元的balance屬性值的銀行賬戶類圖。
類操作列表 類操作記錄在類圖長方形的第三個(最低的)區域中,它也是可選擇的。和屬性一樣,類的操作以列表格式顯示,每個操作在它自己線上。操作使用下列記號表現:
下面的表 2 中Flight類操作的映射。 表 2:從圖 2 映射的Flight類的操作
圖3顯示,delayFlight 操作有一個Minutes類型的輸入參數 -- numberOfMinutes。然而,delayFlight 操作沒有返回值。1 當一個操作有參數時,參數被放在操作的括號內;每個參數都使用這樣的格式:“參數名:參數類型”。 圖 3:Flight類操作參數,包括可選擇的“in”標識。
當文檔化操作參數時,你可能使用一個可選擇的指示器,以顯示參數到操作的輸入參數、或輸出參數。這個可選擇的指示器以“in”或“out”出現,如圖3中的操作區域所示。一般來說,除非將使用一種早期的程序編程語言,如Fortran ,這些指示器可能會有所幫助,否則它們是不必要的。然而,在 C++和Java中,所有的參數是“in”參數,而且按照UML規範,既然“in”是參數的默認類型,大多數人將會遺漏輸入/輸出指示器。 繼承 在面向對象的設計中一個非常重要的概念,繼承,指的是一個類(子類)繼承另外的一個類(超類)的同一功能,並增加它自己的新功能(一個非技術性的比喻,想象我繼承了我母親的一般的音樂能力,但是在我的家裏,我是唯一一個玩電吉他的人)的能力。爲了在一個類圖上建模繼承,從子類(要繼承行爲的類)拉出一條閉合的,單鍵頭(或三角形)的實線指向超類。考慮銀行賬戶的類型:圖 4 顯示 CheckingAccount 和 SavingsAccount 類如何從 BankAccount 類繼承而來。 圖 4: 繼承通過指向超類的一條閉合的,單箭頭的實線表示。
在圖 4 中,繼承關係由每個超類的單獨的線畫出,這是在IBM Rational Rose和IBM Rational XDE中使用的方法。然而,有一種稱爲 樹標記的備選方法可以畫出繼承關係。當存在兩個或更多子類時,如圖 4 中所示,除了繼承線象樹枝一樣混在一起外,你可以使用樹形記號。圖 5 是重繪的與圖 4 一樣的繼承,但是這次使用了樹形記號。 圖 5: 一個使用樹形記號的繼承實例
抽象類及操作 然而,超類(父類)不一定要是抽象類。標準類作爲超類是正常的。 關聯 雙向(標準)的關聯 圖 6:在一個Flight類和Plane類之間的雙向關聯的實例
一個雙向關聯用兩個類間的實線表示。在線的任一端,你放置一個角色名和多重值。圖 6 顯示Flight與一個特定的Plane相關聯,而且Flight類知道這個關聯。因爲角色名以Plane類表示,所以Plane承擔關聯中的“assignedPlane”角色。緊接於Plane類後面的多重值描述0...1表示,當一個Flight實體存在時,可以有一個或沒有Plane與之關聯(也就是,Plane可能還沒有被分配)。圖 6 也顯示Plane知道它與Flight類的關聯。在這個關聯中,Flight承擔“assignedFlights”角色;圖 6 的圖告訴我們,Plane實體可以不與flight關聯(例如,它是一架全新的飛機)或與沒有上限的flight(例如,一架已經服役5年的飛機)關聯。 由於對那些在關聯尾部可能出現的多重值描述感到疑惑,下面的表3列出了一些多重值及它們含義的例子。 表 3: 多重值和它們的表示
單向關聯 圖 7: 單向關聯一個實例:OverdrawnAccountsReport 類 BankAccount 類,而 BankAccount 類則對關聯一無所知。
一個單向的關聯,表示爲一條帶有指向已知類的開放箭頭(不關閉的箭頭或三角形,用於標誌繼承)的實線。如同標準關聯,單向關聯包括一個角色名和一個多重值描述,但是與標準的雙向關聯不同的時,單向關聯只包含已知類的角色名和多重值描述。在圖 7 中的例子中,OverdrawnAccountsReport 知道 BankAccount 類,而且知道 BankAccount 類扮演“overdrawnAccounts”的角色。然而,和標準關聯不同,BankAccount 類並不知道它與 OverdrawnAccountsReport 相關聯。2 軟件包 在圖中存在兩種方法表示軟件包。並沒有規則要求使用哪種標記,除了用你個人的判斷:哪種更便於閱讀你畫的類圖。兩種方法都是由一個較小的長方形(用於定位)嵌套在一個大的長方形中開始的,如圖 8 所示。但是建模者必須決定包的成員如何表示,如下:
圖 8:在軟件包的長方形內顯示軟件包成員的軟件包元素例子
圖 9:一個通過連接線表現軟件包成員的軟件包例子
瞭解基礎重要性 在 UML 2 中,瞭解類圖的基礎更爲重要。這是因爲類圖爲所有的其他結構圖提供基本的構建塊。如組件或對象圖(僅僅是舉了些例子)。 超過基礎 接口 關於何時、以及如何高效地在系統結構圖中使用數據類型和接口的完整討論,不在本文的討論範圍之內。既然這樣,我爲什麼要在這裏提及數據類型和接口呢?你可能想在結構圖上模仿這些分類器類型,在這個時候,使用正確的記號來表示,或者至少知道這些分類器類型是重要的。不正確地繪製這些分類器,很有可能將使你的結構圖讀者感到混亂,以後的系統將不能適應需求。 一個類和一個接口不同:一個類可以有它形態的真實實例,然而一個接口必須至少有一個類來實現它。在 UML 2 中,一個接口被認爲是類建模元素的特殊化。因此,接口就象類那樣繪製,但是長方形的頂部區域也有文本“interface”,如圖 10 所示。5 圖 10:Professor類和Student類實現Person接口的類圖實例
在圖 10 中顯示的圖中,Professor和Student類都實現了Person的接口,但並不從它繼承。我們知道這一點是由於下面兩個原因:1) Person對象作爲接口被定義 -- 它在對象的名字區域中有“interface”文本,而且我們看到由於Professor和Student對象根據畫類對象的規則(在它們的名字區域中沒有額外的分類器文本)標示,所以它們是 類對象。 2) 我們知道繼承在這裏沒有被顯示,因爲與帶箭頭的線是點線而不是實線。如圖 10 所示,一條帶有閉合的單向箭頭的點 線意味着實現(或實施);正如我們在圖 4 中所見到的,一條帶有閉合單向箭頭的實線表示繼承。 更多的關聯 關聯類 圖 11:增加關聯類 MileageCredit
在圖 11 中顯示的類圖中,在Flight類和 FrequentFlyer 類之間的關聯,產生了稱爲 MileageCredit的關聯類。這意味當Flight類的一個實例關聯到 FrequentFlyer 類的一個實例時,將會產生 MileageCredit 類的一個實例。 聚合 舉例來說,我們可以想象,車 是一個整體實體,而 車輪 輪胎是整輛車的一部分。輪胎可以在安置到車時的前幾個星期被製造,並放置於倉庫中。在這個實例中,Wheel類實例清楚地獨立地Car類實例而存在。然而,有些情況下, 部分 類的生命週期並 不 獨立於 整體 類的生命週期 -- 這稱爲合成聚合。舉例來說,考慮公司與部門的關係。 公司和部門 都建模成類,在公司存在之前,部門不能存在。這裏Department類的實例依賴於Company類的實例而存在。 讓我們更進一步探討基本聚合和組合聚合。 基本聚合 圖 12: 一個聚合關聯的例子
組合聚合 圖 13: 一個組合關係的例子
在圖 13 中的關係建模中,一個Company類實例至少總有一個Department類實例。因爲關係是組合關係,當Company實例被移除/銷燬時,Department實例也將自動地被移除/銷燬。組合聚合的另一個重要功能是部分類只能與父類的實例相關(舉例來說,我們例子中的Company類)。 反射關聯 圖 14:一個反射關聯關係的實例
圖 14 描繪的關係說明一個Employee實例可能是另外一個Employee實例的經理。然而,因爲“manages”的關係角色有 0..*的多重性描述;一個僱員可能不受任何其他僱員管理。 可見性 UML 規範並不要求屬性及操作可見性必須顯示在類圖上,但是它要求爲每個屬性及操作定義可見性。爲了在類圖上的顯示可見性,放置可見性標誌於屬性或操作的名字之前。雖然 UML 指定四種可見性類型,但是實際的編程語言可能增加額外的可見性,或不支持 UML 定義的可見性。表4顯示了 UML 支持的可見性類型的不同標誌。 表 4:UML 支持的可見性類型的標誌
現在,讓我們看一個類,以說明屬性及操作的可見性類型。在圖 15 中,所有的屬性及操作都是public,除了 updateBalance 操作。updateBalance 操作是protected。 圖 15:一個 BankAccount 類說明它的屬性及操作的可見性
UML 2 補充 實例 實例的記號和類一樣,但是取代頂端區域中僅有的類名,它的名字是經過拼接的:
舉例來說:
因爲顯示實例的目的是顯示值得注意的或相關的信息,沒必要在你的模型中包含整個實體屬性及操作。相反地,僅僅顯示感興趣的屬性及其值是完全恰當的。如圖16所描述。 圖 16:Plane類的一個實例例子(只顯示感興趣的屬性值)
然而,僅僅表現一些實例而沒有它們的關係不太實用;因此,UML 2 也允許在實體層的關係/關聯建模。繪製關聯與一般的類關係的規則一樣,除了在建模關聯時有一個附加的要求。附加的限制是,關聯關係必須與類圖的關係相一致,而且關聯的角色名字也必須與類圖相一致。它的一個例子顯示於圖 17 中。在這個例子中,實例是圖 6 中類圖的例子實例。 圖 17:圖 6 中用實例代替類的例子
圖 17 有Flight類的二個實例,因爲類圖指出了在Plane類和Flight類之間的關係是 0或多。因此,我們的例子給出了兩個與NX0337 Plane實例相關的Flight實例。 角色 圖 18:一個類圖顯示圖14中扮演不同角色的類 注意,你不能在純粹類圖中做類角色的建模,即使圖 18顯示你可以這麼做。爲了使用角色記號,你將會需要使用下面討論的內部結構記號。 內部的結構 讓我們看一個實例。在圖 18 中我們有一個類圖以表現一個Plane類如何由四個引擎和兩個控制軟件對象組成。從這個圖中省略的東西是顯示關於飛機部件如何被裝配的一些信息。從圖 18 的圖,你無法說明,是每個控制軟件對象控制兩個引擎,還是一個控制軟件對象控制三個引擎,而另一個控制一個引擎。 圖 19: 只顯示對象之間關係的類圖
繪製類的內在結構將會改善這種狀態。開始時,你通過用二個區域畫一個方格。最頂端的區域包含類名字,而較低的區域包含類的內部結構,顯示在它們父類中承擔不同角色的部分類,角色中的每個部分類也關係到其它類。圖 19 顯示了Plane類的內部結構;注意內部結構如何澄清混亂性。 圖 20:Plane類的內部結構例子。
在圖 20 中Plane有兩個 ControlSoftware 對象,而且每個控制二個引擎。在圖左邊上的 ControlSoftware(control1)控制引擎 1 和 2 。在圖右邊的 ControlSoftware(control2)控制引擎 3 和 4 。 結論 關於“UML 基礎”的本系列的後面的元件圖。 腳註 2可能看起來很奇怪, BankAccount 類不知道 OverdrawnAccountsReport 類。這個建模使報表類可以知道它們報告的業務類,但是業務類不知道它們正在被報告。這解開兩個對象的耦合,並因此使系統變得更能適應變化。 3 軟件包對於組織你的模型類是龐大的,但是記住重要的一點是,你的類圖應該是關於建模系統的容易交流的信息。在你的軟件包有許多類的情況下,最好使用多個主題類圖,而不是僅僅產生一個大的類圖。 4 要理解重要一點,當我說“所有的那些成員”時,我僅僅意味着在當前圖中的類將顯示出來。顯示一個有內容的軟件包的圖,不需要顯示它的所有內容。它可以依照一些準則,顯示包含元素的子集,這個準則就是並非所有的軟件包分類器都是必需的。 5 當畫一個類圖時,在 UML 規範中,全部要做的只是把類放入長方形的頂部區域,而你同理處理接口;然而,UML 規範認爲,在這個區域放置“class”文本是可選的,如果類沒有顯示,那麼它應該被假設。 |