全面認識UML類圖元素

開發Java應用程序時,開發者要想有效地利用統一建模語言(UML),必須全面理解UML元素以及這些元素如何映射到Java
本文重點討論UML類圖中的元素。類圖是最常用的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)是聚合的一種特殊形式,暗示“局部”在“整體”內部的生存期職責。合成也是非共享的。所以,雖然局部不一定要隨整體的
銷燬而被銷燬,但整體要麼負責保持局部的存活狀態,要麼負責將其銷燬。局部不可與其他整體共享。但是,整體可將所有權轉交給另一個
對象,後者隨即將承擔生存期職責。
EmployeeTimeCard的關係或許更適合表示成“合成”,而不是表示成“關聯”。
G
泛化(Generalization)
泛化(圖H)表示一個更泛化的元素和一個更具體的元素之間的關係。泛化是用於對繼承進行建模的UML元素。在Java中,用extends關鍵字來
直接表示這種關係。
H
實現(Realization)
實例(圖I)關係指定兩個實體之間的一個合同。換言之,一個實體定義一個合同,而另一個實體保證履行該合同。對Java應用程序進行建模時,
實現關係可直接用implements關鍵字來表示。
I
 
 
 
 
 
 
 
 
 
 
 
精確映射
如本文所述,UML類圖上的元素能精確映射到Java編程語言。開發團隊的成員可利用這種精確性來加強溝通,取得對系統結構化設計的共識。
本文來自CSDN博客,轉載請標明出處:http://blog.csdn.net/parngoo/archive/2006/03/27/639850.aspx
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章