類圖

類圖

類圖(Class diagram)是顯示了模型的靜態結構,特別是模型中存在的類、類的內部結構以及它們與其他類的關係等。類圖不顯示暫時性信息。類圖(Class diagram)由許多(靜態)說明性的模型元素(例如類、包和它們之間的關係,這些元素和它們的內容互相連線)組成。類圖可以組織在(並且屬於)包中,僅顯示特定包中的相關內容。類圖(Class diagram)是最常用的UML圖,顯示出類、接口以及它們之間的靜態結構和關係;它用於描述系統的結構化設計。

基本信息

概述

類圖模擬圖類圖模擬圖

類圖(Classdiagram)由許多(靜態)說明性的模型元素(例如類、包和它們之間的關係,這些元素和它們的內容互相連線)組成。類圖可以組織在(並且屬於)包中,僅顯示特定包中的相關內容。

類圖(Classdiagram)是最常用的UML圖,顯示出類、接口以及它們之間的靜態結構和關係;它用於描述系統的結構化設計。類圖(Classdiagram)最基本的元素是類或者接口。

內容

接口

協作

關係

同其他的圖一樣,類圖也可以包含註解和限制。

類圖中也可以包含包和子系統,這兩者用來將元素的分組。有時候你也可以將類的實例放到類圖中。

註:組件圖和分布圖和類圖類似,雖然他們不包含類而是分別包含組件和節點。

使用類圖

為系統辭彙建模型

為系統的辭彙建模實際上是從辭彙表中發現類,發現它的責任。

模型化簡單的協作

協作是指一些類、接口和其他的元素一起工作提供一些合作的行為,這些行為不是簡單地將元素加能得到的。例如:當你為一個分散式的系統中的事務處理過程建模型時,你不可能只通過一個類來明白事務是怎樣進行的,事實上這個過程的執行涉及到一系列的類的協同工作。使用類圖來可視化這些類和他們的關係。

模型化一個邏輯資料庫模式

想像模式是概念上設計 資料庫的藍圖。在很多領域,你將想保存持久性數據到 關係資料庫或 面向對象的資料庫。你可以用類圖為這些資料庫模式建立模型。

(Class)

一般包含3個組成部分。第一個是類名;第二個是屬性(attributes);第三個是該類提供的方法( 類的性質可以放在第四部分;如果類中含有內部類,則會出現第五個組成部分)。類名部分是不能省略的,其他組成部分可以省略。

類名書寫規範:正體字說明類是可被實例化的,斜體字說明類為抽象類。

屬性和方法書寫規範:修飾符 [描述信息] 屬性、方法名稱 [參數] [:返回類型|類型]

屬性和方法之前可附加的可見性修飾符:

加號(+)表示public;減號(-)表示private;#號表示protected;省略這些修飾符表示具有package(包)級別的可見性。

如果屬性或方法具有下劃線,則說明它是靜態的。

描述信息使用 << 開頭和使用 >> 結尾。

類的性質是由一個屬性、一個 賦值方法和一個取值方法組成。書寫方式和方法類似。

(Package)

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

接口

(Interface)

接口是一系列操作的集合,它指定了一個類所提供的服務。它直接對應於Java中的一個接口類型。接口的表示有大概兩種方式。具體畫法見下例:

關係

常見的關係有:繼承(Inheritance),關聯關係(Association),聚合關係(Aggregation),複合關係(Composition),依賴關係(Dependency)。

其中,聚合關係(Aggregation),複合關係(Composition)屬於關聯關係(Association)。

一般關係表現為繼承或實現關係(is a),關聯關係表現為變數(has a ),依賴關係表現為函式中的參數(use a)。

一般化關係:表示為類與類之間的繼承關係,接口與接口之間的繼承,類對接口的實現關係。

表示方法: 用一個空心箭頭+實線,箭頭指向父類。或空心箭頭+虛線,如果父類是接口。

關聯關係:類與類之間的聯接,它使一個類知道另一個類的屬性和方法。

表示方法:用 實線+箭頭, 箭頭指向被使用的類。

聚合關係:是關聯關係的一種,是強的關聯關係。聚合關係是整體和個體的關係。關聯關係的兩個類處於同一層次上,而聚合關係兩個類處於不同的層次,一個是整體,一個是部分。

表示方法:空心菱形+實線+箭頭,箭頭指向部分。

合成關係:是關聯關係的一種,是比聚合關係強的關係。它要求普通的聚合關係中代表整體的 對象負責代表部分的對象的生命周期,合成關係不能共享。

表示方法:實心菱形+實線+箭頭,

依賴關係:是類與類之間的連線,表示一個類依賴於另一個類的 定義。例如如果A依賴於B,則B體現為 局部變數,方法的參數、或靜態方法的調用。

表示方法:虛線+箭頭 箭頭指向被依賴的一方,也就是指向局部變數。

通用技術

umi類圖umi類圖

沒有類是單獨存在的,他們通常和別的類協作,創造比單獨工作更大的語義。因此,除了捕獲系統的辭彙以外,還要將注意力集中到這些類是如何在一起工作的。使用類圖來表達這種協作。

確定你建模的機制。機制代表了部分你建模的系統的一些功能和行為,這些功能和行為是一組類、接口和其他事物相互作用的結果。

對於每個機制,確定類、接口和其他的參與這個協作的協作。同時確定這些事物之間的關係。

用場景來預排這些事物,沿著這條路你將發現模型中忽略的部分和定義錯誤的部分。

確定用這些事物的內容來填充它們。對於類,開始於獲得一個責任(類的職責),然後,將它轉化為具體的屬性和方法。

圖7-1是一個自治機器人的類圖。這張的圖焦點聚集那些讓機器人在路上行走的機制對應的類上。你可以發現一個虛類Motor和兩個從它派生出來的類:SteeringMotor和MainMotor。這兩個類都從它的父親Motor繼承了五個方法。這兩個類又是另一個類Driver的一部分。類PathAgent和Driver有一個1對1的關係,和CollisionSensor有1對n的關係。

在這個系統中其實還有很多其他的類,但這張圖的重點是放在那些將機器人移動的類上的。在其他的圖中你可能也會看到這些類。通過將焦點放在不通的功能上,可以獲得從不通的角度對整個系統的認識,最終達到認識整個系統。

很多系統都是有持久性數據的,也就是說要將這些數據保存到資料庫中以便下一次使用。通常你會使用關係型資料庫或面向對象的資料庫,或其它類型的資料庫來保存數據。UML很適合為邏輯資料庫模式建模。

UML的類圖是E-R圖(為邏輯資料庫建模的通用工具)的超集,儘管E-R圖的重點是數據,類圖的擴展允許模型化行為。在物理資料庫中這些邏輯操作一半轉化為觸發器或存儲過程。

確定那些狀態比其生命周期要長的類。

創建一張包含這些類的圖,標記它們為持久性的。

詳細定義它們的屬性。

對於使得物理資料庫設計複雜的模式如:循環關係、1對1關係、N元關係,考慮創建中間抽象來使得邏輯結構複雜。

如果可能的話使用工具來將你的邏輯設計轉化為物理設計。

建模是重要的,但要記住的是對於開發組來說軟體才是主要的產品,而不是圖。當然,畫圖的主要目的是為了更好地理解系統,預測什麼時候可以提供什麼樣的軟體來滿足用戶的需要。基於這個理由,讓你畫的圖對開發有指導意義是很重要的。

某些時候,使用UML。你的模型並不能直接映射成為代碼。例如,如果你在使用活動圖為一個商業過程建模,很多活動實際上涉及人而不是計算機。

很多時候,你創建的圖形可以被映射成為代碼。UML並不是專門為面向對象的語言設計的,它支持多種語言,但使用面向對象的語言會更直觀些,特別是類圖的映射,它的內容可以直接映射成為面向對象語言的內容。如:C++,SMALLTALK、ADA、ObjectPascal、Eiffel和Forte。UML還支持如VisualBasic這樣的面向對象的語言。

正向工程:是從圖到代碼的過程。通過對某中特定語言的映射可以從UML的圖得到該語言的代碼。正向工程會丟失信息,這是因為UML比任何一種程式語言的語義都豐富。這也正是為什麼你需要UML模型的原因。結構特性、協作、互動等可以通過UML直觀地表達出來,使用代碼就不是那么明顯了。

其他信息

l 選擇將圖形映射到哪一種程式語言。

l 根據你選擇的語言的語義,你可能要對使用某寫UML的特性加以限制。例如:UML允許你使用多重繼承,而SmallTalk只允許一重繼承。

l 使用標記值來指定比的目的語言。你可以在類級進行也可以在 協作或包的層次上進行。

l 使用工具來對你的模型進行正向工程。

反向工程:反向工程是從代碼到模型的過程。

進行反向工程:

l 確定將你的程式語言的代碼反向成模型的規則。

l 使用工具(Rose C++ Analyzer)進行反向工程。

提示和技巧

一個結構化好的類圖:

l 焦點放在系統靜態 設計視圖的一個方面。

l 只包含為了理解該方面而應該存在的元素。

l 提供足夠的信息來理解該圖。

l 不讓讀者產生錯誤的信息。

當你畫類圖的時候:

l 給它起一個名字,這個名字能表達類圖的用途。

l 用最少的交叉線來組織它的元素。

相關搜尋

熱門詞條

聯絡我們