另一種情況是整體擁有各部分,部分與整體共存,如整體不存在了,部分也會 隨之消失,這稱為組成(Composition)。例如,我們打開一個視窗口,它就由標題、外框和 顯示區所組成。一旦消亡則各部分同時消失。在UML中,聚集表示為空心菱形,組成表示為 實心菱形。
需要注意的是,一些面向對象大師對聚集的定義并不一樣。大家應注意其他面向對象 方法與UML中所定義的聚集的差別。
(4) 繼承關系 人們將具有共同特性的元素抽象成類別,并通過增加其內涵而進一步分類。
例如,動 物可分為飛鳥和走獸,人可分為男人和女人。在面向對象方法中將前者稱為一般元素、基 類元素或父元素,將后者稱為特殊元素或子元素。繼承(Generalization)定義了一般元素 和特殊元素之間的分類關系。在UML中,繼承表示為一頭為空心三角形的連線。如圖1中, 將客戶進一步分類成個體客戶和團體客戶,使用的就是繼承關系。 在UML定義中對繼承有三個要求:
*特殊元素應與一般元素完全一致,一般元素所具有的關聯、屬性和操作,特殊元素也 都隱含性地具有; *特殊元素還應包含額外信息;
*允許使用一般元素實例的地方,也應能使用特殊元素。
(5) 依賴關系 有兩個元素X、Y,如果修改元素X的定義可能會引起對另一個元素Y的定義的修改,則 稱元素Y依賴(Dependency)于元素X。在類中,依賴由各種原因引起,如:一個類向另一個類 發消息;一個類是另一個類的數據成員;一個類是另一個類的某個操作參數。如果一個類 的界面改變,它發出的任何消息可能不再合法。
(6) 類圖的抽象層次和細化(Refinement)關系 需要注意的是,雖然在軟件開發的不同階段都使用類圖,但這些類圖表示了不同層次 的抽象。在需求分析階段,類圖是研究領域的概念;在設計階段,類圖描述類與類之間的接 口;而在實現階段,類圖描述軟件系統中類的實現。按照Steve Cook和John Dianiels的觀 點,類圖分為三個層次。需要說明的是,這個觀點同樣也適合于其他任何模型,只是在類圖 中顯得更為突出。
概念層 概念層(Conceptual)類圖描述應用領域中的概念。實現它們的類可以從這 些概念中得出,但兩者并沒有直接的映射關系。
事實上,一個概念模型應獨立于實現它的 軟件和程序設計語言。 說明層 說明層(Specification)類圖描述軟件的接口部分,而不是軟件的實現部分 。
面向對象開發方法非常重視區別接口與實現之間的差異,但在實際應用中卻常常忽略這 一差異。這主要是因為OO語言中類的概念將接口與實現合在了一起。大多數方法由于受 到語言的影響,也仿效了這一做法�，F在這種情況正在發生變化�？梢杂靡粋�類型(Type )描述一個接口,這個接口可能因為實現環境、運行特性或者用戶的不同而具有多種實現 。
實現層 只有在實現層(Implementation)才真正有類的概念,并且揭示軟件的實現部 分。這可能是大多數人最常用的類圖,但在很多時候,說明層的類圖更易于開發者之間的 相互理解和交流。 理解以上層次對于畫類圖和讀懂類圖都是至關重要的。但是由于各層次之間沒有一 個清晰的界限,所以大多數建模者在畫圖時沒能對其加以區分。畫圖時,要從一個清晰的 層次觀念出發;而讀圖時,則要弄清它是根據哪種層次觀念來繪制的。要正確地理解類圖 ,首先應正確地理解上述三種層次。雖然將類圖分成三個層次的觀點并不是UML的組成部 分,但是它們對于建�；蛘咴u價模型非常有用。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
