1. 程式人生 > >UML類圖java程式碼實現

UML類圖java程式碼實現

類圖是最常用的UML圖,它用於描述系統的結構化設計。其中包括類關係以及與每個類關聯的屬性及行為。類圖能出色地表示繼承與合成關係。為了將類圖作為一種高效的溝通工具使用,開發者必須理解如何將類圖上出現的元素轉換到Java中。下面來進一步探索這一轉換過程。 
元素

在後面的小節中,分別講解了類圖的各個元素及其在Java中相應的表示。我會列出元素名,後續簡短的程式碼片斷和一幅圖來表示元素在類圖上的樣子。每一節的最後簡要總結了該元素。

類(Class)

類(圖A)是物件的藍圖,其中包含3個組成部分。第一個是Java中定義的類名。第二個是屬性(attributes)。第三個是該類提供的方法。

屬性和操作之前可附加一個可見性修飾符。加號(+)表示具有公共可見性。減號(-)表示私有可見性。#號表示受保護的可見性。省略這些修飾符表示具有package(包)級別的可見性。如果屬性或操作具有下劃線,表明它是靜態的。在操作中,可同時列出它接受的引數,以及返回型別,如圖A的“Java”區域所示。


圖A





包(Package)

包(圖B)是一種常規用途的組合機制。UML中的一個包直接對應於Java中的一個包。在Java中,一個包可能含有其他包、類或者同時含有這兩者。進行建模時,你通常擁有邏輯性的包,它主要用於對你的模型進行組織。你還會擁有物理性的包,它直接轉換成系統中的Java包。每個包的名稱對這個包進行了惟一性的標識。

圖B



介面(Interface)

介面(圖C)是一系列操作的集合,它指定了一個類所提供的服務。它直接對應於Java中的一個介面型別。介面既可用圖C的那個圖示來表示,也可由附加了<<interface>>的一個標準類來表示。通常,根據介面在類圖上的樣子,就能知道與其他類的關係。


圖C


關係

後面的例子將針對某個具體目的來獨立地展示各種關係。雖然語法無誤,但這些例子可進一步精煉,在它們的有效範圍內包括更多的語義。

依賴(Dependency)

實體之間一個“使用”關係暗示一個實體的規範發生變化後,可能影響依賴於它的其他例項(圖D)。更具體地說,它可轉換為對不在例項作用域內的一個類或物件的任何型別的引用。其中包括一個區域性變數,對通過方法呼叫而獲得的一個物件的引用(如下例所示),或者對一個類的靜態方法的引用(同時不存在那個類的一個例項)。也可利用“依賴”來表示包和包之間的關係。由於包中含有類,所以你可根據那些包中的各個類之間的關係,表示出包和包的關係。

圖D



關聯(Association)


實體之間的一個結構化關係表明物件是相互連線的。箭頭是可選的,它用於指定導航能力。如果沒有箭頭,暗示是一種雙向的導航能力。在Java中,關聯(圖E)轉換為一個例項作用域的變數,就像圖E的“Java”區域所展示的程式碼那樣。可為一個關聯附加其他修飾符。多重性(Multiplicity)修飾符暗示著例項之間的關係。在示範程式碼中,Employee可以有0個或更多的TimeCard物件。但是,每個TimeCard只從屬於單獨一個Employee。

圖E


聚合(Aggregation)

聚合(圖F)是關聯的一種形式,代表兩個類之間的整體/區域性關係。聚合暗示著整體在概念上處於比區域性更高的一個級別,而關聯暗示兩個類在概念上位於相同的級別。聚合也轉換成Java中的一個例項作用域變數。

關聯和聚合的區別純粹是概念上的,而且嚴格反映在語義上。聚合還暗示著例項圖中不存在迴路。換言之,只能是一種單向關係。

圖F




合成(Composition)



合成 (圖G)是聚合的一種特殊形式,暗示“區域性”在“整體”內部的生存期職責。合成也是非共享的。所以,雖然區域性不一定要隨整體的銷燬而被銷燬,但整體要麼負責保持區域性的存活狀態,要麼負責將其銷燬。區域性不可與其他整體共享。但是,整體可將所有權轉交給另一個物件,後者隨即將承擔生存期職責。

Employee和TimeCard的關係或許更適合表示成“合成”,而不是表示成“關聯”。

圖G


泛化(Generalization)

泛化(圖H)表示一個更泛化的元素和一個更具體的元素之間的關係。泛化是用於對繼承進行建模的UML元素。在Java中,用extends關鍵字來直接表示這種關係。

圖H



實現(Realization)

例項(圖I)關係指定兩個實體之間的一個合同。換言之,一個實體定義一個合同,而另一個實體保證履行該合同。對Java應用程式進行建模時,實現關係可直接用implements關鍵字來表示。

圖I