1. 程式人生 > >看懂UML類圖

看懂UML類圖

spl oci reg 圖片 sso 線表 常識 參數 title

這裏不會將UML的各種元素都提到,我只想講講類圖中各個類之間的關系;能看懂類圖中各個類之間的線條、箭頭代表什麽意思後,也就足夠應對日常的工作和交流; 同時,我們應該能將類圖所表達的含義和最終的代碼對應起來; 有了這些知識,再看那些UML圖就沒有太大的問題了。

從一個示例開始

技術分享圖片


  1. 車的類圖結構為<<abstract>>,表示車是一個抽象類;
  2. 它有兩個繼承類:小汽車和自行車;它們之間的關系為實現關系,使用帶空心箭頭的虛線表示;
  3. 小汽車為與SUV之間也是繼承關系,它們之間的關系為泛化關系,使用帶空心箭頭的實線表示;
  4. 小汽車與發動機之間是組合關系,使用帶實心箭頭的實線表示;
  5. 學生與班級之間是聚合關系,使用帶空心箭頭的實線表示;
  6. 學生與身份證之間為關聯關系,使用一根實線表示;
  7. 學生上學需要用到自行車,與自行車是一種依賴關系,使用帶箭頭的虛線表示;

下面我們將介紹這六種關系。

類之間的關系

泛化關系(generalization)

類的繼承結構表現在UML中為:泛化(generalize)與實現(realize)。

繼承關系為is-a的關系;兩個對象之間如果可以用is-a來表示,就是繼承關系:(..是..)

例如:自行車是車、貓是動物。泛化關系用一條帶空心箭頭的直接表示;如下圖表示(A繼承自B);

技術分享圖片 例如:汽車在現實中有實現,可用汽車定義具體的對象;汽車與SUV之間為泛化關系。

技術分享圖片

註:最終代碼中,泛化關系表現為繼承非抽象類

實現關系(realize)

實現關系用一條帶空心箭頭的虛線表示。

例如:"車"為一個抽象概念,在現實中並無法直接用來定義對象;只有指明具體的子類(汽車還是自行車),才可用來定義對象("車"這個類在C++中用抽象類表示,在JAVA中有接口這個概念,更容易理解)

技術分享圖片

註:最終代碼中,實現關系表現為繼承抽象類

聚合關系(aggregation)

聚合關系用一條帶空心菱形箭頭的直線表示,如下圖表示A聚合到B上,或者說B由A組成。

技術分享圖片 聚合關系用於表示實體對象之間的關系,表示整體由部分構成的語義;例如一個部門由多個員工組成;

與組合關系不同的是,整體和部分不是強依賴的,即使整體不存在了,部分仍然存在;例如, 部門撤銷了,人員不會消失,他們依然存在。

組合關系(composition)

組合關系用一條帶實心菱形箭頭直線表示,如下圖表示A組成B,或者B由A組成。

技術分享圖片

與聚合關系一樣,組合關系同樣表示整體由部分構成的語義;比如公司由多個部門組成;

但組合關系是一種強依賴的特殊聚合關系,如果整體不存在了,則部分也不存在了;例如, 公司不存在了,部門也將不存在了。

關聯關系(association)

關聯關系是用一條直線表示的;它描述不同類的對象之間的結構關系;它是一種靜態關系, 通常與運行狀態無關,一般由常識等因素決定的;它一般用來定義對象之間靜態的、天然的結構; 所以,關聯關系是一種"強關聯"的關系。

比如,乘車人和車票之間就是一種關聯關系;學生和學校就是一種關聯關系。

關聯關系默認不強調方向,表示對象間相互知道;如果特別強調方向,如下圖,表示A知道B,但 B不知道A。

技術分享圖片

註:在最終代碼中,關聯對象通常是以成員變量的形式實現的

依賴關系(dependency)

依賴關系是用一套帶箭頭的虛線表示的;如下圖表示A依賴於B;他描述一個對象在運行期間會用到另一個對象的關系。

技術分享圖片

與關聯關系不同的是,它是一種臨時性的關系,通常在運行期間產生,並且隨著運行時的變化; 依賴關系也可能發生變化。

顯然,依賴也有方向,雙向依賴是一種非常糟糕的結構,我們總是應該保持單向依賴,杜絕雙向依賴的產生。

註:在最終代碼中,依賴關系體現為類構造方法及類方法的傳入參數,箭頭的指向為調用關系;依賴關系除了臨時知道對方外,還是"使用"對方的方法和屬性;

看懂UML類圖