專(zhuān)家講解在UML中如何表示Java繼承和UML接口

作者：yzq124391 2010-07-08 10:33:34

UML接口的概念你是否熟悉，本文向大家介紹一下如何在UML中表示兩個(gè)重要的Java概念——繼承，UML接口。希望本文的介紹對(duì)你有所幫助。

本文和大家重點(diǎn)討論一下在UML中表示Java繼承和UML接口

在UML中表示Java繼承和UML接口

在上一篇文章中，我們引入了UML類(lèi)圖的概念，比較了在Java編程語(yǔ)言和UML類(lèi)圖中表示類(lèi)、屬性、操作和關(guān)聯(lián)關(guān)系的不同之處。下面我們來(lái)看看如何在UML中表示兩個(gè)重要的Java概念——繼承，UML接口。

繼承

在Java中，我們可以聲明一個(gè)類(lèi)擴(kuò)展（extends）另一個(gè)類(lèi)，還可以聲明一個(gè)類(lèi)實(shí)現(xiàn)（implements）一個(gè)或者多個(gè)接口。下面我們來(lái)看看如何在UML中表達(dá)這些概念。
圖一用UML顯示了同樣的三個(gè)類(lèi)。在操作和屬性聲明中，類(lèi)型和參數(shù)之類(lèi)的細(xì)節(jié)都沒(méi)有顯示出來(lái)，這是為了更清楚地顯示出類(lèi)的整體結(jié)構(gòu)以及各個(gè)類(lèi)之間的關(guān)系。

圖一：UML一般化關(guān)系

Java中的extends關(guān)鍵詞聲明了繼承關(guān)系，相當(dāng)于UML中的“一般化”（Generalization，也譯為“泛化”）關(guān)系，在UML圖形中用子類(lèi)向超類(lèi)的實(shí)線空心封閉箭頭表示。圖一額外增加了一個(gè)Sale類(lèi)，這是為了更清楚地說(shuō)明UML一般化關(guān)系與UML定向關(guān)聯(lián)關(guān)系所用箭頭的不同。關(guān)聯(lián)關(guān)系與一般化關(guān)系的另一個(gè)不同之處在于，一般化關(guān)系的兩端不需要說(shuō)明多重性或角色名稱(chēng)。
　
顯然，UML類(lèi)圖比三個(gè)Java源代碼文件更清楚直觀地顯示出了三個(gè)類(lèi)之間的繼承關(guān)系。如果你要與別人探討設(shè)計(jì)思路，繪制UML草圖也要比直接使用代碼簡(jiǎn)單快捷得多。
也許有人會(huì)說(shuō)，系統(tǒng)的類(lèi)結(jié)構(gòu)圖就在他們的頭腦中，他們只需要直接使用Java代碼。實(shí)際上，對(duì)于規(guī)模較大的系統(tǒng)，這種說(shuō)法顯然是不成立的；即使對(duì)于規(guī)模較小的系統(tǒng)，如果一定的時(shí)間之后要由其他程序員修改，沒(méi)有UML圖也會(huì)寸步難行——很難保證每一個(gè)人都了解你頭腦中的類(lèi)結(jié)構(gòu)圖。

在Java繼承和UML接口中，抽象類(lèi)的標(biāo)志是類(lèi)的名字以斜體顯示。在白板或紙張上手工畫(huà)UML草圖時(shí)，很難區(qū)分字體是否是斜體。為此，一些人建議這些場(chǎng)合可以在類(lèi)名稱(chēng)的右下角加上{abstract}標(biāo)記以示區(qū)別。
另一些人認(rèn)為，在白板上寫(xiě){abstract}顯得太羅嗦，他們傾向于打破UML常規(guī)，在類(lèi)名稱(chēng)的右下角加上一個(gè)0表示零個(gè)實(shí)例，如果在該位置寫(xiě)上1，則表示該類(lèi)是一個(gè)singleton類(lèi)（永遠(yuǎn)只有一個(gè)實(shí)例的類(lèi)）；如果在該位置寫(xiě)上N，則表示它是一個(gè)枚舉類(lèi)（擁有固定實(shí)例數(shù)量的類(lèi)，如一星期中的天數(shù)，彩虹的顏色，等等）。不過(guò)，這一切都不是標(biāo)準(zhǔn)的UML，只能用于手工繪制UML圖的場(chǎng)合，看來(lái)也不可能得到UML建模工具的支持。

歷史知識(shí)：UML首先由Rational公司的一個(gè)工作組發(fā)明，Ration公司是UML建模工具Rose的生產(chǎn)者。UML于1995年的OOPSLA會(huì)議上被公諸于世，隨后，OMG（對(duì)象管理組織）于1997年采用了UML規(guī)范。不難理解，繼續(xù)負(fù)責(zé)發(fā)展UML規(guī)范的OMG任務(wù)組包含了來(lái)自幾乎所有主流UML工具廠商的代表。因此，除了嚴(yán)格遵從規(guī)范的UML軟件工具，在一些書(shū)籍或網(wǎng)頁(yè)上發(fā)現(xiàn)不規(guī)范的UML符號(hào)也不足為怪。

繼承使得一個(gè)類(lèi)能夠使用另一個(gè)類(lèi)的屬性和方法，就象使用自己的屬性和方法一樣。當(dāng)這類(lèi)繼承機(jī)制第一次出現(xiàn)時(shí)，人們普遍把它視為重用現(xiàn)有代碼的理想方法。令人遺憾的是，規(guī)模過(guò)于龐大的繼承樹(shù)變得很脆弱，修改繼承樹(shù)的一部分，就會(huì)在整棵繼承樹(shù)中引起一系列的連帶反映。在面向?qū)ο蟮木幊讨校绻獙?shí)現(xiàn)有效的封裝，就應(yīng)該讓改動(dòng)局部化，即一個(gè)地方的改動(dòng)不至于引起其他地方的變化。而修改繼承樹(shù)一個(gè)地方引起其他地方的變化恰恰違背了上述設(shè)計(jì)思想。UML圖使得我們能夠方便地掌握繼承關(guān)系圖，從而為應(yīng)用繼承關(guān)系帶來(lái)了方便。那么，什么時(shí)候適合運(yùn)用繼承關(guān)系呢？按照《JavaDesign》一書(shū)，對(duì)于超類(lèi)A和子類(lèi)B，執(zhí)行如下檢：

命題“B是一個(gè)由A扮演的角色”不成立。
B永遠(yuǎn)不需要變形成為其他某些類(lèi)別中的對(duì)象。
B擴(kuò)展而不是覆蓋或廢棄A的行為。
A不僅僅是一個(gè)工具類(lèi)（一些可以重用的實(shí)用功能）。
對(duì)于一個(gè)問(wèn)題域（特定的業(yè)務(wù)對(duì)象環(huán)境）：A和B定義了同一類(lèi)型的對(duì)象，或者是用戶(hù)事務(wù)、角色、實(shí)體（團(tuán)體、位置或其他東西），或其他物體的相似類(lèi)別。

如果上述任意一個(gè)判斷不成立，那么把A和B定義成繼承關(guān)系可能是不合適的，改用關(guān)聯(lián)關(guān)系可能更加穩(wěn)固、正確。例如，圖二違背上面的第一個(gè)判斷，因?yàn)?ldquo;雇員是一個(gè)由人扮演的角色”成立。另外，它還違背了第二個(gè)判斷，因?yàn)楣蛦T確實(shí)可能改變其類(lèi)別（身份），例如某個(gè)時(shí)候它可能是顧客。這樣，一個(gè)既是顧客又是雇員的人就要有兩個(gè)獨(dú)立的對(duì)象來(lái)描述，從而使保存在Person類(lèi)里面的信息重復(fù)出現(xiàn)，帶來(lái)了兩個(gè)數(shù)據(jù)副本之間數(shù)據(jù)不一致的風(fēng)險(xiǎn)。#p#

UML接口

Java編程語(yǔ)言中接口（Interface）的概念也能夠與UML概念匹配。UML中的接口是一種實(shí)現(xiàn)繼承的形式，但這種繼承形式與Java中通過(guò)關(guān)鍵詞extends實(shí)現(xiàn)的繼承有所不同。

在Java中，extends關(guān)鍵詞描述了一種繼承形式，它既繼承接口也繼承行為。這種類(lèi)型的繼承有時(shí)被稱(chēng)為Sub-classing。與其他的面象對(duì)象編程語(yǔ)言不同，Java類(lèi)只能從一個(gè)類(lèi)繼承。許多時(shí)候，設(shè)計(jì)UML圖的人熟悉多種編程語(yǔ)言，常常會(huì)引入多重繼承的思想，例如C++的多重繼承思想。從已有的Java代碼生成UML圖（這個(gè)過(guò)程稱(chēng)為反向工程）不會(huì)帶來(lái)多重繼承的問(wèn)題，但如果要求一個(gè)Java程序員去實(shí)現(xiàn)一個(gè)帶有多重繼承的UML類(lèi)圖，就會(huì)出現(xiàn)問(wèn)題。如果多重繼承中的超類(lèi)是純抽象類(lèi)，這部分類(lèi)可以用Java的接口來(lái)描述，但是，如果只做這種轉(zhuǎn)換不足以把UML類(lèi)圖中的多重繼承全部轉(zhuǎn)換成單重繼承，這時(shí)就必須修改UML類(lèi)圖重新建模了。

雖然Java不支持C++之類(lèi)語(yǔ)言那樣的多重繼承，但它支持實(shí)現(xiàn)多重UML接口。這種由Java關(guān)鍵詞implements聲明的繼承只繼承接口，這種繼承有時(shí)被稱(chēng)作Sub-typing。在UML中，實(shí)現(xiàn)接口的類(lèi)與接口定義之間的關(guān)系叫做Realization關(guān)系，用一個(gè)虛線封閉箭頭表示，從實(shí)現(xiàn)接口的類(lèi)指向UML接口。接口本身的UML圖與普通類(lèi)一樣，但它的名字上面要加上“<>”。圖四由圖一修改而成，Payment類(lèi)被一個(gè)接口取代。（關(guān)于Realization名稱(chēng)的說(shuō)明：Realization最常見(jiàn)的中文譯名是“實(shí)現(xiàn)”。但是，Java的implements也叫做“實(shí)現(xiàn)”。為避免混淆，本文中凡是出現(xiàn)Realization的地方一律直接使用英文）。

Java中UML接口可以從一個(gè)或者多個(gè)其他接口擴(kuò)展。
UML一般化關(guān)系（實(shí)線封閉箭頭）可用來(lái)描述這種關(guān)系，如圖五所示。UML還支持另一種接口符號(hào)，即用圓圈表示接口（加上連線之后就成了棒棒糖的樣子），但這種表示法多用于UML組件圖，在UML類(lèi)圖中比較少見(jiàn)。如果UML圖規(guī)模較大，有大量的類(lèi)實(shí)現(xiàn)一個(gè)常用接口，整個(gè)UML圖可能亂成一團(tuán)糟。《JavaDesign》一書(shū)提出了一種簡(jiǎn)化方法，后來(lái)又被《StreamlinedObjectModeling》一書(shū)的作者采用，這就是在實(shí)現(xiàn)接口的類(lèi)中，用接口的名字替代從接口繼承的方法，不過(guò)這不屬于標(biāo)準(zhǔn)方法。遺憾的是，目前似乎還沒(méi)有工具支持這種轉(zhuǎn)換。

結(jié)束語(yǔ)：

繼承和接口是Java語(yǔ)言中非常有用的機(jī)制，我們已經(jīng)看到，可以用UML的一般化和Realization關(guān)系使得Java的這兩個(gè)概念可視化。另外，一些非標(biāo)準(zhǔn)化的表示方法能夠極大地簡(jiǎn)化UML圖。在下一篇文章中，我們將了解如何在Java程序中保留無(wú)法直接表達(dá)的UML語(yǔ)義信

【編輯推薦】