(5) 依賴關系
有兩個元素X、Y,如果修改元素X的定義可能會引起對另一個元素Y的定義的修改,則稱元素Y依賴(Dependency)于元素X。在類中,依賴由各種原因引起,如:一個類向另一個類發消息;一個類是另一個類的數據成員;一個類是另一個類的某個操作參數。如果一個類的界面改變,它發出的任何消息可能不再合法。
(6) 類圖的抽象層次和細化(Refinement)關系
需要注意的是,雖然在軟件開發的不同階段都使用類圖,但這些類圖表示了不同層次的抽象。在需求分析階段,類圖是研究領域的概念;在設計階段,類圖描述類與類之間的接口;而在實現階段,類圖描述軟件系統中類的實現。按照Steve Cook和John Dianiels的觀點,類圖分為三個層次。需要說明的是,這個觀點同樣也適合于其他任何模型,只是在類圖中顯得更為突出。
概念層 概念層(Conceptual)類圖描述應用領域中的概念。實現它們的類可以從這些概念中得出,但兩者并沒有直接的映射關系。事實上,一個概念模型應獨立于實現它的軟件和程序設計語言。
說明層 說明層(Specification)類圖描述軟件的接口部分,而不是軟件的實現部分。面向對象開發方法非常重視區別接口與實現之間的差異,但在實際應用中卻常常忽略這一差異。這主要是因為OO語言中類的概念將接口與實現合在了一起。大多數方法由于受到語言的影響,也仿效了這一做法�，F在這種情況正在發生變化�？梢杂靡粋�類型(Type )描述一個接口,這個接口可能因為實現環境、運行特性或者用戶的不同而具有多種實現。
實現層 只有在實現層(Implementation)才真正有類的概念,并且揭示軟件的實現部分。這可能是大多數人最常用的類圖,但在很多時候,說明層的類圖更易于開發者之間的相互理解和交流。
理解以上層次對于畫類圖和讀懂類圖都是至關重要的。但是由于各層次之間沒有一個清晰的界限,所以大多數建模者在畫圖時沒能對其加以區分。畫圖時,要從一個清晰的層次觀念出發;而讀圖時,則要弄清它是根據哪種層次觀念來繪制的。要正確地理解類圖,首先應正確地理解上述三種層次。雖然將類圖分成三個層次的觀點并不是UML的組成部分,但是它們對于建�；蛘咴u價模型非常有用。盡管迄今為止人們似乎更強調實現層類圖,但這三個層次都可應用于UML,而且實際上另外兩個層次的類圖更有用。
下面介紹細化概念。細化是UML中的術語,表示對事物更詳細一層的描述。兩個元素A、B描述同一件事物,它們的區別是抽象層次不同,若元素B是在元素A的基礎上的更詳細的描述,則稱元素B細化了元素A,或稱元素A細化成元素B。細化的圖形表示為由元素B指向元素A的、一頭為空心三角的虛線(千萬不要把方向顛倒了!)。細化主要用于模型之間的合作,表示開發各階段不同層次抽象模型的相關性,常用于跟蹤模型的演變。
(7) 約束
在UML中,可以用約束(Constraint)表示規則。約束是放在括號"{}"中的一個表達式,表示一個永真的邏輯陳述。在程序設計語言中,約束可以由斷言(Assertion)來實現。
(8) 對象圖、對象和鏈
UML中對象圖與類圖具有相同的表示形式。對象圖可以看作是類圖的一個實例。對象是類的實例;對象之間的鏈(Link)是類之間的關聯的實例。對象與類的圖形表示相似,均為劃分成兩個格子的長方形(下面的格子可省略)。上面的格子是對象名,對象名下有下劃線;下面的格子記錄屬性值。鏈的圖形表示與關聯相似。對象圖常用于表示復雜的類圖的一個實例。
(9) 包
一個最古老的軟件方法問題是:怎樣將大系統拆分成小系統。解決這個問題的一個思路是將許多類集合成一個更高層次的單位,形成一個高內聚、低耦合的類的集合。這個思路被松散地應用到許多對象技術中。UML中這種分組機制叫包(Package)(見圖5)。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
