解析UML的靜態(tài)建模機(jī)制

1、解析UML的靜態(tài)建模機(jī)制（1）作者：51CMM 本文選自：51CMM 2002年12月10日 任何建模語(yǔ)言都以靜態(tài)建模機(jī)制為基礎(chǔ)，標(biāo)準(zhǔn)建模語(yǔ)言UML也不例外。UML的靜態(tài)建模機(jī)制包括用例圖(Use case diagram)、類(lèi)圖(Class diagram)、對(duì)象圖(Object diagram )、包(Package)、構(gòu)件圖(Component diagram)和配置圖(Deployment diagram)。 用例圖用例模型(Use case model) 長(zhǎng)期以來(lái)，在面向?qū)ο箝_(kāi)發(fā)和傳統(tǒng)的軟件開(kāi)發(fā)中，人們根據(jù)典型的使用情景來(lái)了解需求。但是，這些使用情景是非正式的，雖然經(jīng)常使用

2、，卻難以建立正式文擋。用例模型由Ivar Jacobson在開(kāi)發(fā)AXE系統(tǒng)中首先使用，并加入由他所倡導(dǎo)的OOSE和Objectory方法中。用例方法引起了面向?qū)ο箢I(lǐng)域的極大關(guān)注。自1994年Ivar Jacobson的著作出版后，面向?qū)ο箢I(lǐng)域已廣泛接納了用例這一概念，并認(rèn)為它是第二代面向?qū)ο蠹夹g(shù)的標(biāo)志。 用例模型描述的是外部執(zhí)行者(Actor)所理解的系統(tǒng)功能。用例模型用于需求分析階段，它的建立是系統(tǒng)開(kāi)發(fā)者和用戶(hù)反復(fù)討論的結(jié)果，表明了開(kāi)發(fā)者和用戶(hù)對(duì)需求規(guī)格達(dá)成的共識(shí)。 首先，它描述了待開(kāi)發(fā)系統(tǒng)的功能需求; 其次，它將系統(tǒng)看作黑盒，從外部執(zhí)行者的角度來(lái)理解系統(tǒng); 第三，它驅(qū)動(dòng)了需求分析之后各階段

3、的開(kāi)發(fā)工作，不僅在開(kāi)發(fā)過(guò)程中保證了系統(tǒng)所有功能的實(shí)現(xiàn)，而且被用于驗(yàn)證和檢測(cè)所開(kāi)發(fā)的系統(tǒng)，從而影響到開(kāi)發(fā)工作的各個(gè)階段和UML的各個(gè)模型。在UML中，一個(gè)用例模型由若干個(gè)用例圖描述，用例圖主要元素是用例和執(zhí)行者。 用例(use case) 從本質(zhì)上講，一個(gè)用例是用戶(hù)與計(jì)算機(jī)之間的一次典型交互作用。以字處理軟件為例，“將某些正文置為黑體”和“創(chuàng)建一個(gè)索引”便是兩個(gè)典型的用例。在UML中，用例被定義成系統(tǒng)執(zhí)行的一系列動(dòng)作，動(dòng)作執(zhí)行的結(jié)果能被指定執(zhí)行者察覺(jué)到。 在UML中，用例表示為一個(gè)橢圓。圖1顯示了一個(gè)金融貿(mào)易系統(tǒng)的用例圖。其中，“風(fēng)險(xiǎn)分析”，“交易估價(jià)”，“進(jìn)行交易”，“設(shè)置邊界”，“超越邊界的

4、交易”，“評(píng)價(jià)貿(mào)易”，“更新帳目”等都是用例的實(shí)例。概括地說(shuō)，用例有以下特點(diǎn): ·用例捕獲某些用戶(hù)可見(jiàn)的需求，實(shí)現(xiàn)一個(gè)具體的用戶(hù)目標(biāo)。 ·用例由執(zhí)行者激活，并提供確切的值給執(zhí)行者。 ·用例可大可小，但它必須是對(duì)一個(gè)具體的用戶(hù)目標(biāo)實(shí)現(xiàn)的完整描述。 圖1 金融貿(mào)易系統(tǒng)用例執(zhí)行者(Actor) 執(zhí)行者是指用戶(hù)在系統(tǒng)中所扮演的角色。其圖形化的表示是一個(gè)小人。圖1中有四個(gè)執(zhí)行者:貿(mào)易經(jīng)理、營(yíng)銷(xiāo)人員、售貨員和記帳系統(tǒng)。在某些組織中很可能有許多營(yíng)銷(xiāo)人員,但就該系統(tǒng)而言,他們均起著同一種作用,扮演著相同的角色,所以用一個(gè)執(zhí)行者表示。一個(gè)用戶(hù)也可以扮演多種角色(執(zhí)行者)。例如,一個(gè)

5、高級(jí)營(yíng)銷(xiāo)人員既可以是貿(mào)易經(jīng)理,也可以是普通的營(yíng)銷(xiāo)人員;一個(gè)營(yíng)銷(xiāo)人員也可以是售貨員。在處理執(zhí)行者時(shí),應(yīng)考慮其作用,而不是人或工作名稱(chēng),這一點(diǎn)是很重要的。 圖1中,不帶箭頭的線(xiàn)段將執(zhí)行者與用例連接到一起,表示兩者之間交換信息,稱(chēng)之為通信聯(lián)系。執(zhí)行者觸發(fā)用例,并與用例進(jìn)行信息交換。單個(gè)執(zhí)行者可與多個(gè)用例聯(lián)系;反過(guò)來(lái),一個(gè)用例可與多個(gè)執(zhí)行者聯(lián)系。對(duì)同一個(gè)用例而言,不同執(zhí)行者有著不同的作用:他們可以從用例中取值,也可以參與到用例中。 需要注意的是執(zhí)行者在用例圖中是用類(lèi)似人的圖形來(lái)表示,盡管執(zhí)行的,但執(zhí)行者未必是人。例如,執(zhí)行者也可以是一個(gè)外界系統(tǒng),該外界系統(tǒng)可能需要從當(dāng)前系統(tǒng)中獲取信息,與當(dāng)前系統(tǒng)有進(jìn)行

6、交互。在圖1中,我們可以看到,記帳系統(tǒng)是一個(gè)外界系統(tǒng),它需要更新帳目。 通過(guò)實(shí)踐,我們發(fā)現(xiàn)執(zhí)行者對(duì)提供用例是非常有用的。面對(duì)一個(gè)大系統(tǒng),要列出用例清單常常是十分困難。這時(shí)可先列出執(zhí)行者清單,再對(duì)每個(gè)執(zhí)行者列出它的用例,問(wèn)題就會(huì)變得容易很多。 使用和擴(kuò)展(Use and Extend) 圖1中除了包含執(zhí)行者與用例之間的連接外,還有另外兩種類(lèi)型的連接,用以表示用例之間的使用和擴(kuò)展關(guān)系。使用和擴(kuò)展是兩種不同形式的繼承關(guān)系。當(dāng)一個(gè)用例與另一個(gè)用例相似,但所做的動(dòng)作多一些,就可以用到擴(kuò)展關(guān)系。例如圖1中,基本的用例是"進(jìn)行交易"。交易中可能一切都進(jìn)行得很順利,但也可能存在擾亂順利進(jìn)行

7、交易的因素。其中之一便是超出某些邊界值的情況。例如,貿(mào)易組織會(huì)對(duì)某個(gè)特定客戶(hù)規(guī)定最大貿(mào)易量,這時(shí)不能執(zhí)行給定用例提供的常規(guī)動(dòng)作,而要做些改動(dòng)。我們可在"進(jìn)行交易"用例中做改動(dòng)。但是,這將把該用例與一大堆特殊的判斷和邏輯混雜在一起,使正常的流程晦澀不堪。圖1中將常規(guī)的動(dòng)作放在"進(jìn)行交易"用例中,而將非常規(guī)的動(dòng)作放置于"超越邊界的交易"用例中,這便是擴(kuò)展關(guān)系的實(shí)質(zhì)。當(dāng)有一大塊相似的動(dòng)作存在于幾個(gè)用例,又不想重復(fù)描述該動(dòng)作時(shí),就可以用到使用關(guān)系。例如,現(xiàn)實(shí)中風(fēng)險(xiǎn)分析和交易估價(jià)都需要評(píng)價(jià)貿(mào)易,為此可單獨(dú)定義一個(gè)用例,即"評(píng)價(jià)貿(mào)易&q

8、uot;,而"風(fēng)險(xiǎn)分析"和"交易估價(jià)"用例將使用它。 請(qǐng)注意擴(kuò)展與使用之間的相似點(diǎn)和不同點(diǎn)。它們兩個(gè)都意味著從幾個(gè)用例中抽取那些公共的行為并放入一個(gè)單獨(dú)用例中,而這個(gè)用例被其他幾個(gè)用例使用或擴(kuò)展。但使用和擴(kuò)展的目的是不同的。 用例模型的獲取 幾乎在任何情況下都會(huì)使用用例。用例用來(lái)獲取需求,規(guī)劃和控制項(xiàng)目。用例的獲取是需求分析階段的主要任務(wù)之一,而且是首先要做的工作。大部分用例將在項(xiàng)目的需求分析階段產(chǎn)生,并且隨著工作的深入會(huì)發(fā)現(xiàn)更多的用例,這些都應(yīng)及時(shí)增添到已有的用例集中。用例集中的每個(gè)用例都是一個(gè)潛在的需求。 1. 獲取執(zhí)行者 獲取用例首先要找出系統(tǒng)的執(zhí)

9、行者?？梢酝ㄟ^(guò)用戶(hù)回答一些問(wèn)題的答案來(lái)識(shí)別執(zhí)行者。以下問(wèn)題可供參考: ·誰(shuí)使用系統(tǒng)的主要功能(主要使用者)。 ·誰(shuí)需要系統(tǒng)支持他們的日常工作。 ·誰(shuí)來(lái)維護(hù)、管理使系統(tǒng)正常工作(輔助使用者)。 ·系統(tǒng)需要操縱哪些硬件。 ·系統(tǒng)需要與哪些其它系統(tǒng)交互,包含其它計(jì)算機(jī)系統(tǒng)和其它應(yīng)用程序。 ·對(duì)系統(tǒng)產(chǎn)生的結(jié)果感興趣的人或事物。 解析UML的靜態(tài)建模機(jī)制（2）作者：51CMM 本文選自：51CMM 2002年12月10日 2. 獲取用例 一旦獲取了執(zhí)行者,就可以對(duì)每個(gè)執(zhí)行者提出問(wèn)題以獲取用例。 以下問(wèn)題可供參考: ·執(zhí)行者要

10、求系統(tǒng)提供哪些功能(執(zhí)行者需要做什么)? ·執(zhí)行者需要讀、產(chǎn)生、刪除、修改或存儲(chǔ)的信息有哪些類(lèi)型。 ·必須提醒執(zhí)行者的系統(tǒng)事件有哪些?或者執(zhí)行者必須提醒系統(tǒng)的事件有哪些?怎樣把這些事件表示成用例中的功能? ·為了完整地描述用例,還需要知道執(zhí)行者的某些典型功能能否被系統(tǒng)自動(dòng)實(shí)現(xiàn)? 還有一些不針對(duì)具體執(zhí)行者問(wèn)題(即針對(duì)整個(gè)系統(tǒng)的問(wèn)題): ·系統(tǒng)需要何種輸入輸出?輸入從何處來(lái)?輸出到何處? ·當(dāng)前運(yùn)行系統(tǒng)(也許是一些手工操作而不是計(jì)算機(jī)系統(tǒng))的主要問(wèn)題? 需要注意,最后兩個(gè)問(wèn)題并不是指沒(méi)有執(zhí)行者也可以有用例,只是獲取用例時(shí)尚不知道執(zhí)行者是什么。一個(gè)用

11、例必須至少與一個(gè)執(zhí)行者關(guān)聯(lián)。還需要注意:不同的設(shè)計(jì)者對(duì)用例的利用程度也不同。例如,Ivar Jacobson說(shuō),對(duì)一個(gè)十人年的項(xiàng)目,他需要二十個(gè)用例。而在一個(gè)相同規(guī)模的項(xiàng)目中,Martin Fowler則用了一百多個(gè)用例。我們認(rèn)為:任何合適的用例都可使用,確定用例的過(guò)程是對(duì)獲取的用例進(jìn)行提煉和歸納的過(guò)程,對(duì)一個(gè)十人年的項(xiàng)目來(lái)說(shuō),二十個(gè)用例似乎太少,一百多個(gè)用例則嫌太多,需要保持二者間的相對(duì)均衡。 類(lèi)圖、對(duì)象圖和包 數(shù)千年以前,人類(lèi)就已經(jīng)開(kāi)始采用分類(lèi)的方法有效地簡(jiǎn)化復(fù)雜問(wèn)題,幫助人們了解客觀世界。在面向?qū)ο蠼＜夹g(shù)中,我們使用同樣的方法將客觀世界的實(shí)體映射為對(duì)象,并歸納成一個(gè)個(gè)類(lèi)。類(lèi)(Class

12、)、對(duì)象(Object)和它們之間的關(guān)聯(lián)是面向?qū)ο蠹夹g(shù)中最基本的元素。對(duì)于一個(gè)想要描述的系統(tǒng),其類(lèi)模型和對(duì)象模型揭示了系統(tǒng)的結(jié)構(gòu)。在UML中,類(lèi)和對(duì)象模型分別由類(lèi)圖和對(duì)象圖表示。類(lèi)圖技術(shù)是OO方法的核心。圖2顯示了一個(gè)金融保險(xiǎn)系統(tǒng)的類(lèi)圖。 圖2 金融保險(xiǎn)系統(tǒng)類(lèi)圖 類(lèi)圖 類(lèi)圖(Class Diagram)描述類(lèi)和類(lèi)之間的靜態(tài)關(guān)系。與數(shù)據(jù)模型不同,它不僅顯示了信息的結(jié)構(gòu),同時(shí)還描述了系統(tǒng)的行為。類(lèi)圖是定義其它圖的基礎(chǔ)。在類(lèi)圖的基礎(chǔ)上,狀態(tài)圖、合作圖等進(jìn)一步描述了系統(tǒng)其他方面的特性。 類(lèi)和對(duì)象 對(duì)象(Object)與我們對(duì)客觀世界的理解相關(guān)。我們通常用對(duì)象描述客觀世界中某個(gè)具體的實(shí)體。所謂類(lèi)(Cla

13、ss)是對(duì)一類(lèi)具有相同特征的對(duì)象的描述。而對(duì)象是類(lèi)的實(shí)例(Instance)。建立類(lèi)模型時(shí),我們應(yīng)盡量與應(yīng)用領(lǐng)域的概念保持一致,以使模型更符合客觀事實(shí),易修改、易理解和易交流。 類(lèi)描述一類(lèi)對(duì)象的屬性(Attribute)和行為(Behavior)。在UML中,類(lèi)的可視化表示為一個(gè)劃分成三個(gè)格子的長(zhǎng)方形(下面兩個(gè)格子可省略)。圖1中,"客戶(hù)"就是一個(gè)典型的類(lèi)。 類(lèi)的獲取和命名最頂部的格子包含類(lèi)的名字。類(lèi)的命名應(yīng)盡量用應(yīng)用領(lǐng)域中的術(shù)語(yǔ),應(yīng)明確、無(wú)歧義,以利于開(kāi)發(fā)人員與用戶(hù)之間的相互理解和交流。類(lèi)的獲取是一個(gè)依賴(lài)于人的創(chuàng)造力的過(guò)程,必須與領(lǐng)域?qū)＜液献?對(duì)研究領(lǐng)域仔細(xì)地分析,抽象出

14、領(lǐng)域中的概念,定義其含義及相互關(guān)系,分析出系統(tǒng)類(lèi),并用領(lǐng)域中的術(shù)語(yǔ)為類(lèi)命名。一般而言,類(lèi)的名字是名詞。 · 類(lèi)的屬性 中間的格子包含類(lèi)的屬性,用以描述該類(lèi)對(duì)象的共同特點(diǎn)。該項(xiàng)可省略。圖2中“客戶(hù)”類(lèi)有"客戶(hù)名"、"地址"等特性。屬性的選取應(yīng)考慮以下因素: *原則上來(lái)說(shuō),類(lèi)的屬性應(yīng)能描述并區(qū)分每個(gè)特定的對(duì)象; *只有系統(tǒng)感興趣的特征才包含在類(lèi)的屬性中; *系統(tǒng)建模的目的也會(huì)影響到屬性的選取。根據(jù)圖的詳細(xì)程度,每條屬性可以包括屬性的可見(jiàn)性、屬性名稱(chēng)、類(lèi)型、缺省值和約束特性。UML規(guī)定類(lèi)的屬性的語(yǔ)法為: 可見(jiàn)性屬性名 :類(lèi)型 = 缺省值約束特性 圖2

15、“客戶(hù)”類(lèi)中,"客戶(hù)名"屬性描述為"- 客戶(hù)名 : 字符串 = 缺省客戶(hù)名"。 可見(jiàn)性"-"表示它是私有數(shù)據(jù)成員,其屬性名為"客戶(hù)名",類(lèi)型為"字符串"類(lèi)型,缺省值為"缺省客戶(hù)名",此處沒(méi)有約束特性。 不同屬性具有不同可見(jiàn)性。常用的可見(jiàn)性有Public、Private和Protected三種,在UML中分別表示為"+"、"-"和"#"。 類(lèi)型表示該屬性的種類(lèi)。它可以是基本數(shù)據(jù)類(lèi)型,例如整數(shù)、實(shí)數(shù)、布爾型等,也可以是用

16、戶(hù)自定義的類(lèi)型。一般它由所涉及的程序設(shè)計(jì)語(yǔ)言確定。 約束特性則是用戶(hù)對(duì)該屬性性質(zhì)一個(gè)約束的說(shuō)明。例如"只讀"說(shuō)明該屬性是只讀屬性。 · 類(lèi)的操作(Operation) 該項(xiàng)可省略。操作用于修改、檢索類(lèi)的屬性或執(zhí)行某些動(dòng)作。操作通常也被稱(chēng)為功能,但是它們被約束在類(lèi)的內(nèi)部,只能作用到該類(lèi)的對(duì)象上。操作名、返回類(lèi)型和參數(shù)表組成操作界面。UML規(guī)定操作的語(yǔ)法為: 可見(jiàn)性 操作名 (參數(shù)表) : 返回類(lèi)型 約束特性 在圖2中,"客戶(hù)"類(lèi)中有"取客戶(hù)地址"操作,其中"+"表示該操作是公有操作,調(diào)用時(shí)需要參數(shù)"

17、;客戶(hù)名",參數(shù)類(lèi)型為字符串,返回類(lèi)型也為字符串。 類(lèi)圖描述了類(lèi)和類(lèi)之間的靜態(tài)關(guān)系。定義了類(lèi)之后,就可以定義類(lèi)之間的各種關(guān)系了。 關(guān)聯(lián)關(guān)系 關(guān)聯(lián)(Association)表示兩個(gè)類(lèi)之間存在某種語(yǔ)義上的聯(lián)系。例如,一個(gè)人為一家公司工作,一家公司有許多辦公室。我們就認(rèn)為人和公司、公司和辦公室之間存在某種語(yǔ)義上的聯(lián)系。在分析設(shè)計(jì)的類(lèi)圖模型中,則在對(duì)應(yīng)人類(lèi)和公司類(lèi)、公司類(lèi)和辦公室類(lèi)之間建立關(guān)聯(lián)關(guān)系。 在圖2中最上部存在一個(gè)"屬于"/"簽定"關(guān)聯(lián):每個(gè)"保險(xiǎn)單"屬于一個(gè)"客戶(hù)",而"客戶(hù)"可以簽

18、定多個(gè)"保險(xiǎn)單"。除了這個(gè)關(guān)聯(lián)外,圖1中還有另外兩個(gè)關(guān)聯(lián),分別表示每個(gè)"保險(xiǎn)單"包含若干個(gè)"保險(xiǎn)單上的項(xiàng)目",而每個(gè)"保險(xiǎn)單上的項(xiàng)目"涉及單一的"保險(xiǎn)類(lèi)別"。 · 關(guān)聯(lián)的方向 關(guān)聯(lián)可以有方向,表示該關(guān)聯(lián)單方向被使用。關(guān)聯(lián)上加上箭頭表示方向,在UML中稱(chēng)為導(dǎo)航(Navigability)。我們將只在一個(gè)方向上存在導(dǎo)航表示的關(guān)聯(lián),稱(chēng)作單向關(guān)聯(lián) ( Uni-directional Association ),在兩個(gè)方向上都有導(dǎo)航表示的關(guān)聯(lián),稱(chēng)作雙向關(guān)聯(lián) ( Bi-directional As

19、sociation )。圖2中,"保險(xiǎn)單"“保險(xiǎn)單上的項(xiàng)目”是單向關(guān)聯(lián)。UML規(guī)定,不帶箭頭的關(guān)聯(lián)可以意味著未知、未確定或者該關(guān)聯(lián)是雙向關(guān)聯(lián)三種選擇,因此,在圖中應(yīng)明確使用其中的一種選擇。 · 關(guān)聯(lián)的命名 既然關(guān)聯(lián)可以是雙向的,最復(fù)雜的命名方法是每個(gè)方向上給出一個(gè)名字,這樣的關(guān)聯(lián)有兩個(gè)名字。（見(jiàn)圖2中最上部的"屬于"/"簽定"關(guān)聯(lián))。為關(guān)聯(lián)命名有幾種方法,其原則是該命名是否有助于理解該模型。 · 角色 關(guān)聯(lián)兩頭的類(lèi)以某種角色參與關(guān)聯(lián)。例如圖3中，"公司"以"雇主"的角色,&q

20、uot;人"以"雇員"的角色參與的"工作合同"關(guān)聯(lián)。"雇主"和"雇員"稱(chēng)為角色名。如果在關(guān)聯(lián)上沒(méi)有標(biāo)出角色名,則隱含地用類(lèi)的名稱(chēng)作為角色名。角色還具有多重性(Multiplicity),表示可以有多少個(gè)對(duì)象參與該關(guān)聯(lián)。在圖3中,雇主(公司)可以雇傭(簽工作合同)多個(gè)雇員,表示為"*"雇員只能與一家雇主簽定工作合同,表示為"1"。多重性表示參與對(duì)象的數(shù)目的上下界限制。"*"代表0,即一個(gè)客戶(hù)可以沒(méi)有保險(xiǎn)單,也可以有任意多的保險(xiǎn)單。"1&q

21、uot;是1.1的簡(jiǎn)寫(xiě),即任何一個(gè)保險(xiǎn)單僅來(lái)自于一個(gè)客戶(hù),可以用一個(gè)單個(gè)數(shù)字表示,也可以用范圍或者是數(shù)字和范圍不連續(xù)的組合表示。 圖3 關(guān)聯(lián)的角色 · 關(guān)聯(lián)類(lèi) 一個(gè)關(guān)聯(lián)可能要記錄一些信息,可以引入一個(gè)關(guān)聯(lián)類(lèi)來(lái)記錄。圖4是在圖3的基礎(chǔ)上引入了關(guān)聯(lián)類(lèi)。關(guān)聯(lián)類(lèi)通過(guò)一根虛線(xiàn)與關(guān)聯(lián)連接。圖5是實(shí)現(xiàn)上述目標(biāo)的另外一種方法,就是使雇用關(guān)系成為一個(gè)正式的類(lèi)。 圖4 關(guān)聯(lián)類(lèi) 圖5 另一種實(shí)現(xiàn)方法 · 聚集和組成 聚集(Aggregation)是一種特殊形式的關(guān)聯(lián)。聚集表示類(lèi)之間的關(guān)系是整體與部分的關(guān)系。一輛轎車(chē)包含四個(gè)車(chē)輪、一個(gè)方向盤(pán)、一個(gè)發(fā)動(dòng)機(jī)和一個(gè)底盤(pán),這是聚集的一個(gè)例子。在需求分析中,

22、"包含"、"組成"、"分為部分"等經(jīng)常設(shè)計(jì)成聚集關(guān)系。聚集可以進(jìn)一步劃分成共享聚集(Shared Aggregation)和組成。例如,課題組包含許多成員,但是每個(gè)成員又可以是另一個(gè)課題組的成員,即部分可以參加多個(gè)整體,我們稱(chēng)之為共享聚集。另一種情況是整體擁有各部分,部分與整體共存,如整體不存在了,部分也會(huì)隨之消失,這稱(chēng)為組成(Composition)。例如,我們打開(kāi)一個(gè)視窗口,它就由標(biāo)題、外框和顯示區(qū)所組成。一旦消亡則各部分同時(shí)消失。在UML中,聚集表示為空心菱形,組成表示為實(shí)心菱形。需要注意的是,一些面向?qū)ο蟠髱煂?duì)聚集的定義并不一

23、樣。大家應(yīng)注意其他面向?qū)ο蠓椒ㄅcUML中所定義的聚集的差別。 繼承關(guān)系 人們將具有共同特性的元素抽象成類(lèi)別,并通過(guò)增加其內(nèi)涵而進(jìn)一步分類(lèi)。例如,動(dòng)物可分為飛鳥(niǎo)和走獸,人可分為男人和女人。在面向?qū)ο蠓椒ㄖ袑⑶罢叻Q(chēng)為一般元素、基類(lèi)元素或父元素,將后者稱(chēng)為特殊元素或子元素。繼承(Generalization)定義了一般元素和特殊元素之間的分類(lèi)關(guān)系。在UML中,繼承表示為一頭為空心三角形的連線(xiàn)。 如圖2中,將客戶(hù)進(jìn)一步分類(lèi)成個(gè)體客戶(hù)和團(tuán)體客戶(hù),使用的就是繼承關(guān)系。 在UML定義中對(duì)繼承有三個(gè)要求: *特殊元素應(yīng)與一般元素完全一致,一般元素所具有的關(guān)聯(lián)、屬性和操作,特殊元素也都隱含性地具有; *特殊元素

24、還應(yīng)包含額外信息; *允許使用一般元素實(shí)例的地方,也應(yīng)能使用特殊元素。 依賴(lài)關(guān)系 有兩個(gè)元素X、Y,如果修改元素X的定義可能會(huì)引起對(duì)另一個(gè)元素Y的定義的修改,則稱(chēng)元素Y依賴(lài)(Dependency)于元素X。在類(lèi)中,依賴(lài)由各種原因引起,如:一個(gè)類(lèi)向另一個(gè)類(lèi)發(fā)消息;一個(gè)類(lèi)是另一個(gè)類(lèi)的數(shù)據(jù)成員;一個(gè)類(lèi)是另一個(gè)類(lèi)的某個(gè)操作參數(shù)。如果一個(gè)類(lèi)的界面改變,它發(fā)出的任何消息可能不再合法。 解析UML的靜態(tài)建模機(jī)制（3）作者：51CMM 本文選自：51CMM 2002年12月10日類(lèi)圖的抽象層次和細(xì)化(Refinement)關(guān)系 需要注意的是,雖然在軟件開(kāi)發(fā)的不同階段都使用類(lèi)圖,但這些類(lèi)圖表示了不同層次的抽象。

25、在需求分析階段,類(lèi)圖是研究領(lǐng)域的概念;在設(shè)計(jì)階段,類(lèi)圖描述類(lèi)與類(lèi)之間的接口;而在實(shí)現(xiàn)階段,類(lèi)圖描述軟件系統(tǒng)中類(lèi)的實(shí)現(xiàn)。按照Steve Cook和John Dianiels的觀點(diǎn),類(lèi)圖分為三個(gè)層次。需要說(shuō)明的是,這個(gè)觀點(diǎn)同樣也適合于其他任何模型,只是在類(lèi)圖中顯得更為突出。 · 概念層 概念層(Conceptual)類(lèi)圖描述應(yīng)用領(lǐng)域中的概念。實(shí)現(xiàn)它們的類(lèi)可以從這些概念中得出,但兩者并沒(méi)有直接的映射關(guān)系。事實(shí)上,一個(gè)概念模型應(yīng)獨(dú)立于實(shí)現(xiàn)它的軟件和程序設(shè)計(jì)語(yǔ)言。 · 說(shuō)明層 說(shuō)明層(Specification)類(lèi)圖描述軟件的接口部分,而不是軟件的實(shí)現(xiàn)部分。面向?qū)ο箝_(kāi)發(fā)方法非常重視區(qū)

26、別接口與實(shí)現(xiàn)之間的差異,但在實(shí)際應(yīng)用中卻常常忽略這一差異。這主要是因?yàn)镺O語(yǔ)言中類(lèi)的概念將接口與實(shí)現(xiàn)合在了一起。大多數(shù)方法由于受到語(yǔ)言的影響,也仿效了這一做法?，F(xiàn)在這種情況正在發(fā)生變化?？梢杂靡粋€(gè)類(lèi)型(Type )描述一個(gè)接口,這個(gè)接口可能因?yàn)閷?shí)現(xiàn)環(huán)境、運(yùn)行特性或者用戶(hù)的不同而具有多種實(shí)現(xiàn)。 · 實(shí)現(xiàn)層 只有在實(shí)現(xiàn)層(Implementation)才真正有類(lèi)的概念,并且揭示軟件的實(shí)現(xiàn)部分。這可能是大多數(shù)人最常用的類(lèi)圖,但在很多時(shí)候,說(shuō)明層的類(lèi)圖更易于開(kāi)發(fā)者之間的相互理解和交流。 理解以上層次對(duì)于畫(huà)類(lèi)圖和讀懂類(lèi)圖都是至關(guān)重要的。但是由于各層次之間沒(méi)有一個(gè)清晰的界限,所以大多數(shù)建模者在畫(huà)

27、圖時(shí)沒(méi)能對(duì)其加以區(qū)分。畫(huà)圖時(shí),要從一個(gè)清晰的層次觀念出發(fā);而讀圖時(shí),則要弄清它是根據(jù)哪種層次觀念來(lái)繪制的。要正確地理解類(lèi)圖,首先應(yīng)正確地理解上述三種層次。雖然將類(lèi)圖分成三個(gè)層次的觀點(diǎn)并不是UML的組成部分,但是它們對(duì)于建模或者評(píng)價(jià)模型非常有用。盡管迄今為止人們似乎更強(qiáng)調(diào)實(shí)現(xiàn)層類(lèi)圖,但這三個(gè)層次都可應(yīng)用于UML,而且實(shí)際上另外兩個(gè)層次的類(lèi)圖更有用。 下面介紹細(xì)化概念。細(xì)化是UML中的術(shù)語(yǔ),表示對(duì)事物更詳細(xì)一層的描述。兩個(gè)元素A、B描述同一件事物,它們的區(qū)別是抽象層次不同,若元素B是在元素A的基礎(chǔ)上的更詳細(xì)的描述,則稱(chēng)元素B細(xì)化了元素A,或稱(chēng)元素A細(xì)化成元素B。細(xì)化的圖形表示為由元素B指向元素A的

28、、一頭為空心三角的虛線(xiàn)(千萬(wàn)不要把方向顛倒了!)。細(xì)化主要用于模型之間的合作,表示開(kāi)發(fā)各階段不同層次抽象模型的相關(guān)性,常用于跟蹤模型的演變。 約束 在UML中,可以用約束(Constraint)表示規(guī)則。約束是放在括號(hào)""中的一個(gè)表達(dá)式,表示一個(gè)永真的邏輯陳述。在程序設(shè)計(jì)語(yǔ)言中,約束可以由斷言(Assertion)來(lái)實(shí)現(xiàn)。 對(duì)象圖、對(duì)象和鏈 UML中對(duì)象圖與類(lèi)圖具有相同的表示形式。對(duì)象圖可以看作是類(lèi)圖的一個(gè)實(shí)例。對(duì)象是類(lèi)的實(shí)例;對(duì)象之間的鏈(Link)是類(lèi)之間的關(guān)聯(lián)的實(shí)例。對(duì)象與類(lèi)的圖形表示相似,均為劃分成兩個(gè)格子的長(zhǎng)方形(下面的格子可省略)。上面的格子是對(duì)象名,對(duì)象名下有

29、下劃線(xiàn);下面的格子記錄屬性值。鏈的圖形表示與關(guān)聯(lián)相似。對(duì)象圖常用于表示復(fù)雜的類(lèi)圖的一個(gè)實(shí)例。 包 一個(gè)最古老的軟件方法問(wèn)題是:怎樣將大系統(tǒng)拆分成小系統(tǒng)。解決這個(gè)問(wèn)題的一個(gè)思路是將許多類(lèi)集合成一個(gè)更高層次的單位,形成一個(gè)高內(nèi)聚、低耦合的類(lèi)的集合。這個(gè)思路被松散地應(yīng)用到許多對(duì)象技術(shù)中。UML中這種分組機(jī)制叫包(Package)(見(jiàn)圖6)。 圖6 包圖不僅是類(lèi),任何模型元素都運(yùn)用包的機(jī)制。如果沒(méi)有任何啟發(fā)性原則來(lái)指導(dǎo)類(lèi)的分組,分組方法就是任意的。在UML中,最有用的和強(qiáng)調(diào)最多的啟發(fā)性原則就是依賴(lài)。包圖主要顯示類(lèi)的包以及這些包之間的依賴(lài)關(guān)系。有時(shí)還顯示包和包之間的繼承關(guān)系和組成關(guān)系。 · 包

30、的內(nèi)容 在圖6中,"系統(tǒng)內(nèi)部"包由"保險(xiǎn)單"包和"客戶(hù)"包組成。這里稱(chēng)"保險(xiǎn)單"包和"客戶(hù)"包為"系統(tǒng)內(nèi)部"包的內(nèi)容。當(dāng)不需要顯示包的內(nèi)容時(shí),包的名字放入主方框內(nèi),否則包的名字放入左上角的小方框中,而將內(nèi)容放入主方框內(nèi)。包的內(nèi)容可以是類(lèi)的列表,也可以是另一個(gè)包圖,還可以是一個(gè)類(lèi)圖。 · 包的依賴(lài)和繼承 圖6中"保險(xiǎn)單填寫(xiě)界面"包依賴(lài)于"保險(xiǎn)單"包;整個(gè)"系統(tǒng)內(nèi)部"包依賴(lài)于"數(shù)據(jù)庫(kù)界面"包

31、。可以使用繼承中通用和特例的概念來(lái)說(shuō)明通用包和專(zhuān)用包之間的關(guān)系。例如,專(zhuān)用包必須符合通用包的界面,與類(lèi)繼承關(guān)系類(lèi)似。通過(guò)"數(shù)據(jù)庫(kù)界面"包,"系統(tǒng)內(nèi)部"包既能夠使用Oracle的界面也可使用Sybase的界面。通用包可標(biāo)記為abs tract,表示該包只是定義了一個(gè)界面,具體實(shí)現(xiàn)則由專(zhuān)用包來(lái)完成。 其他模型元素和表示機(jī)制 類(lèi)圖中用到的模型元素和表示機(jī)制較為豐富,由于篇幅的限制,這里不能一一介紹。主要還有以下模型符號(hào)和概念:類(lèi)別模板(Stereotype)、界面(Interface)、參數(shù)化類(lèi)(P arameterized Class)也稱(chēng)模板類(lèi)(Templ

32、ate)、限定關(guān)聯(lián)(Qualified Association)、多維關(guān)聯(lián)(N-ary Association)、多維鏈(N-ary Link)、派生(Derived)、類(lèi)型(Type)和注釋(Note)等。 使用類(lèi)圖的幾個(gè)建議 類(lèi)圖幾乎是所有OO方法的支柱。采用標(biāo)準(zhǔn)建模語(yǔ)言UML進(jìn)行建模時(shí),必須對(duì)UML類(lèi)圖引入的各種要素有清晰的理解。以下對(duì)使用類(lèi)圖進(jìn)行建模提出幾點(diǎn)建議: *不要試圖使用所有的符號(hào)。從簡(jiǎn)單的開(kāi)始,例如,類(lèi)、關(guān)聯(lián)、屬性和繼承等概念。在UML中,有些符號(hào)僅用于特殊的場(chǎng)合和方法中,只有當(dāng)需要時(shí)才去使用。 *根據(jù)項(xiàng)目開(kāi)發(fā)的不同階段,用正確的觀點(diǎn)來(lái)畫(huà)類(lèi)圖。如果處于分析階段,應(yīng)畫(huà)概念層類(lèi)圖

33、;當(dāng)開(kāi)始著手軟件設(shè)計(jì)時(shí),應(yīng)畫(huà)說(shuō)明層類(lèi)圖;當(dāng)考察某個(gè)特定的實(shí)現(xiàn)技術(shù)時(shí),則應(yīng)畫(huà)實(shí)現(xiàn)層類(lèi)圖。 *不要為每個(gè)事物都畫(huà)一個(gè)模型,應(yīng)該把精力放在關(guān)鍵的領(lǐng)域。最好只畫(huà)幾張較為關(guān)鍵的圖,經(jīng)常使用并不斷更新修改。使用類(lèi)圖的最大危險(xiǎn)是過(guò)早地陷入實(shí)現(xiàn)細(xì)節(jié)。為了避免這一危險(xiǎn),應(yīng)該將重點(diǎn)放在概念層和說(shuō)明層。如果已經(jīng)遇到了一些麻煩,可以從以下幾個(gè)方面來(lái)反思你的模型。 *模型是否真實(shí)地反映了研究領(lǐng)域的實(shí)際。 *模型和模型中的元素是否有清楚的目的和職責(zé)(在面向?qū)ο蠓椒ㄖ?系統(tǒng)功能最終是分配到每個(gè)類(lèi)的操作上實(shí)現(xiàn)的,這個(gè)機(jī)制叫職責(zé)分配)。 *模型和模型元素的大小是否適中。過(guò)于復(fù)雜的模型和模型元素是很難生存的,應(yīng)將其分解成幾個(gè)相互合作的部分。 構(gòu)件圖和配置圖構(gòu)件圖(Component diagram)和配置圖(Deploymen