解析UML的靜態建模機制（3）

需要注意的是,雖然在軟件開發的不同階段都使用類圖,但這些類圖表示了不同層次的抽象。在需求分析階段,類圖是研究領域的概念;在設計階段,類圖描述類與類之間的接口;而在實現階段,類圖描述軟件系統中類的實現。按照Steve Cook和John Dianiels的觀點,類圖分為三個層次。需要說明的是,這個觀點同樣也適合于其他任何模型,只是在類圖中顯得更為突出。

· 概念層

概念層(Conceptual)類圖描述應用領域中的概念。實現它們的類可以從這些概念中得出,但兩者并沒有直接的映射關系。事實上,一個概念模型應獨立于實現它的軟件和程序設計語言。

· 說明層

說明層(Specification)類圖描述軟件的接口部分,而不是軟件的實現部分。面向對象開發方法非常重視區別接口與實現之間的差異,但在實際應用中卻常常忽略這一差異。這主要是因為OO語言中類的概念將接口與實現合在了一起。大多數方法由于受到語言的影響,也仿效了這一做法?，F在這種情況正在發生變化?？梢杂靡粋€類型(Type )描述一個接口,這個接口可能因為實現環境、運行特性或者用戶的不同而具有多種實現。

· 實現層

只有在實現層(Implementation)才真正有類的概念,并且揭示軟件的實現部分。這可能是大多數人最常用的類圖,但在很多時候,說明層的類圖更易于開發者之間的相互理解和交流。

理解以上層次對于畫類圖和讀懂類圖都是至關重要的。但是由于各層次之間沒有一個清晰的界限,所以大多數建模者在畫圖時沒能對其加以區分。畫圖時,要從一個清晰的層次觀念出發;而讀圖時,則要弄清它是根據哪種層次觀念來繪制的。要正確地理解類圖,首先應正確地理解上述三種層次。雖然將類圖分成三個層次的觀點并不是UML的組成部分,但是它們對于建?；蛘咴u價模型非常有用。盡管迄今為止人們似乎更強調實現層類圖,但這三個層次都可應用于UML,而且實際上另外兩個層次的類圖更有用。

下面介紹細化概念。細化是UML中的術語,表示對事物更詳細一層的描述。兩個元素A、B描述同一件事物,它們的區別是抽象層次不同,若元素B是在元素A的基礎上的更詳細的描述,則稱元素B細化了元素A,或稱元素A細化成元素B。細化的圖形表示為由元素B指向元素A的、一頭為空心三角的虛線(千萬不要把方向顛倒了!)。細化主要用于模型之間的合作,表示開發各階段不同層次抽象模型的相關性,常用于跟蹤模型的演變。

約束

在UML中,可以用約束(Constraint)表示規則。約束是放在括號"{}"中的一個表達式,表示一個永真的邏輯陳述。在程序設計語言中,約束可以由斷言(Assertion)來實現。

對象圖、對象和鏈

UML中對象圖與類圖具有相同的表示形式。對象圖可以看作是類圖的一個實例。對象是類的實例;對象之間的鏈(Link)是類之間的關聯的實例。對象與類的圖形表示相似,均為劃分成兩個格子的長方形(下面的格子可省略)。上面的格子是對象名,對象名下有下劃線;下面的格子記錄屬性值。鏈的圖形表示與關聯相似。對象圖常用于表示復雜的類圖的一個實例。

包

一個最古老的軟件方法問題是:怎樣將大系統拆分成小系統。解決這個問題的一個思路是將許多類集合成一個更高層次的單位,形成一個高內聚、低耦合的類的集合。這個思路被松散地應用到許多對象技術中。UML中這種分組機制叫包(Package)(見圖6)。

圖6 包圖

不僅是類,任何模型元素都運用包的機制。如果沒有任何啟發性原則來指導類的分組,分組方法就是任意的。在UML中,最有用的和強調最多的啟發性原則就是依賴。包圖主要顯示類的包以及這些包之間的依賴關系。有時還顯示包和包之間的繼承關系和組成關系。

· 包的內容

在圖6中,"系統內部"包由"保險單"包和"客戶"包組成。這里稱"保險單"包和"客戶"包為"系統內部"包的內容。當不需要顯示包的內容時,包的名字放入主方框內,否則包的名字放入左上角的小方框中,而將內容放入主方框內。包的內容可以是類的列表,也可以是另一個包圖,還可以是一個類圖。

· 包的依賴和繼承

圖6中"保險單填寫界面"包依賴于"保險單"包;整個"系統內部"包依賴于"數據庫界面"包?？梢允褂美^承中通用和特例的概念來說明通用包和專用包之間的關系。例如,專用包必須符合通用包的界面,與類繼承關系類似。通過"數據庫界面"包,"系統內部"包既能夠使用Oracle的界面也可使用Sybase的界面。通用包可標記為{abs tract},表示該包只是定義了一個界面,具體實現則由專用包來完成。

其他模型元素和表示機制

類圖中用到的模型元素和表示機制較為豐富,由于篇幅的限制,這里不能一一介紹。主要還有以下模型符號和概念:類別模板(Stereotype)、界面(Interface)、參數化類(P arameterized Class)也稱模板類(Template)、限定關聯(Qualified Association)、多維關聯(N-ary Association)、多維鏈(N-ary Link)、派生(Derived)、類型(Type)和注釋(Note)等。

使用類圖的幾個建議

類圖幾乎是所有OO方法的支柱。采用標準建模語言UML進行建模時,必須對UML類圖引入的各種要素有清晰的理解。以下對使用類圖進行建模提出幾點建議:

*不要試圖使用所有的符號。從簡單的開始,例如,類、關聯、屬性和繼承等概念。在UML中,有些符號僅用于特殊的場合和方法中,只有當需要時才去使用。

*根據項目開發的不同階段,用正確的觀點來畫類圖。如果處于分析階段,應畫概念層類圖;當開始著手軟件設計時,應畫說明層類圖;當考察某個特定的實現技術時,則應畫實現層類圖。

*不要為每個事物都畫一個模型,應該把精力放在關鍵的領域。最好只畫幾張較為關鍵的圖,經常使用并不斷更新修改。使用類圖的最大危險是過早地陷入實現細節。為了避免這一危險,應該將重點放在概念層和說明層。如果已經遇到了一些麻煩,可以從以下幾個方面來反思你的模型。

*模型是否真實地反映了研究領域的實際。

*模型和模型中的元素是否有清楚的目的和職責(在面向對象方法中,系統功能最終是分配到每個類的操作上實現的,這個機制叫職責分配)。

*模型和模型元素的大小是否適中。過于復雜的模型和模型元素是很難生存的,應將其分解成幾個相互合作的部分。

構件圖和配置圖

構件圖(Component diagram)和配置圖(Deployment diagram)顯示系統實現時的一些特性,包括源代碼的靜態結構和運行時刻的實現結構。構件圖顯示代碼本身的結構,配置圖顯示系統運行時刻的結構。

(1) 構件圖構件圖顯示軟件構件之間的依賴關系。一般來說,軟件構件就是一個實際文件,可以是源代碼文件、二進制代碼文件和可執行文件等?？梢杂脕盹@示編譯、鏈接或執行時構件之間的依賴關系。

(2) 配置圖配置圖描述系統硬件的物理拓撲結構以及在此結構上執行的軟件。配置圖可以顯示計算結點的拓撲結構和通信路徑、結點上運行的軟件構件、軟件構件包含的邏輯單元(對象、類)等。配置圖常常用于幫助理解分布式系統。

(3) 結點和連接　結點(Node)代表一個物理設備以及其上運行的軟件系統,如一臺Unix主機、一個PC終端、一臺打印機、一個傳感器等。如圖1所示,"客戶端PC"和"保險后臺服務器"就是兩個結點。結點表示為一個立方體,結點名放在左上角。

結點之間的連線表示系統之間進行交互的通信路徑,在UML中被稱為連接(Connectio n)。通信類型則放在連接旁邊的"《》"之間,表示所用的通信協議或網絡類型。

(4) 構件和界面　在配置圖中,構件代表可執行的物理代碼模塊,如一個可執行程序。邏輯上它可以與類圖中的包或類對應。因此,配置圖中顯示運行時各個包或類在結點中的分布情況。如在圖1中,"保險后臺服務器" 結點中包含"保險系統"、"保險對象數據庫"和"保險系統配置"3個構件。在面向對象方法中,類和構件等元素并不是所有的屬性和操作都對外可見。它們對外提供了可見操作和屬性,稱之為類和構件的界面。界面可以表示為一頭是小園圈的直線。圖1中,"保險系統"構件提供了一個"配置"界面。配置圖中還顯示了構件之間的依賴關系,"保險系統配置"構件依賴于這個"配置"界面。

(5) 對象(Object)　一個面向對象軟件系統中可以運行很多對象。由于構件可以看作與包或類對應的物理代碼模塊,因此,構件中應包含一些運行的對象。配置圖中的對象與對象圖中的對象表示法一樣。圖1中,"保險系統配置"構件包含"配置保險政策"和"配置用戶"兩個對象。

標準建模語言UML的靜態建模機制是采用UML進行建模的基礎。我們認為,熟練掌握基本概念、區分不同抽象層次以及在實踐中靈活運用,是三條最值得注意的基本原則。