UML中各種圖的畫法全

1、UML中各種圖的畫法(全)一、UML中基本的圖范疇：在 UML 2 中有二種基本的圖范疇：結(jié)構(gòu)圖和行為圖。每個(gè) UML 圖都屬于這二個(gè)圖范疇。結(jié)構(gòu)圖的目的是顯示建模系統(tǒng)的靜態(tài)結(jié)構(gòu)。它們包括類，組件和（或）對(duì)象圖。另一方面，行為圖顯示系統(tǒng)中的對(duì)象的動(dòng)態(tài)行為，包括如對(duì)象的方法，協(xié)作和活動(dòng)之類的內(nèi)容。行為圖的實(shí)例是活動(dòng)圖，用例圖和序列圖。二、UML中的類圖：1.類圖的表示：類的 UML 表示是一個(gè)長方形，垂直地分為三個(gè)區(qū)，如圖 1 所示。頂部區(qū)域顯示類的名字。中間的區(qū)域列出類的屬性。底部的區(qū)域列出類的操作。在一個(gè)類圖上畫一個(gè)類元素時(shí)，你必須要有頂端的區(qū)域，下面的二個(gè)區(qū)域是可 選擇的（當(dāng)圖描述僅僅用于

2、顯示分類器間關(guān)系的高層細(xì)節(jié)時(shí)，下面的兩個(gè)區(qū)域是不必要的）。描述：頂部區(qū)域顯示類的名字。中間的區(qū)域列出類的屬性。底部的區(qū)域列出類的操作。當(dāng)在一個(gè)類圖上畫一個(gè)類元素時(shí)，你必須要有頂端的區(qū)域，下面的二個(gè)區(qū)域是可選擇的（當(dāng)圖描述僅僅用于顯示分類器間關(guān)系的高層細(xì)節(jié)時(shí)，下面的兩個(gè)區(qū)域是不必要的）。·類名：如果是抽象類，則采用斜體·類屬性列表：name : attribute type 如 flightNumber : Integer，這是最常見的表達(dá)形式          &#

3、160;      name : attribute type = default value  如 balance : Dollars = 0，這是帶有默認(rèn)值的表達(dá)形式·類方法列表：name(parameter list) : type of value returned注意：在業(yè)務(wù)類圖中，屬性類型通常與單位相符，這對(duì)于圖的可能讀者是有意義的（例如，分鐘，美元，等等）。然而，用于生成代碼的類圖，要求類的屬性類型必須限制在由程序語言提供的類型之中，或包含于在系統(tǒng)中實(shí)現(xiàn)的、模型的類型之中。2.繼承

4、的表示：為了在一個(gè)類圖上建模繼承，從子類（要繼承行為的類）拉出一條閉合的，單鍵頭（或三角形）的實(shí)線指向超類。類名BankAccount和withdrawal操作使用斜體。這表示，BankAccount 類是一個(gè)抽象類，而withdrawal方法是抽象的操作。換句話說，BankAccount 類使用withdrawal規(guī)定抽象操作，并且CheckingAccount 和 SavingsAccount 兩個(gè)子類都分別地執(zhí)行它們各自版本的操作。3.接口的表示：一個(gè)類和一個(gè)接口不同：一個(gè)類可以有它形態(tài)的真實(shí)實(shí)例，然而一個(gè)接口必須至少有一個(gè)類來實(shí)現(xiàn)它。在 UML 2 中，一個(gè)接口被認(rèn)為是類建模元素的特殊

5、化。因此，接口就象類那樣繪制，但是長方形的頂部區(qū)域也有文本“interface”。注意：繼承用帶箭頭或三角形的實(shí)線表示，實(shí)現(xiàn)用帶箭頭或三角形的虛線表示4.可見性的表示：在面向?qū)ο蟮脑O(shè)計(jì)中，存在屬性及操作可見性的記號(hào)。UML 識(shí)別四種類型的可見性：public，protected，private及package。UML 規(guī)范并不要求屬性及操作可見性必須顯示在類圖上，但是它要求為每個(gè)屬性及操作定義可見性。為了在類圖上顯示可見性，放置可見性標(biāo)志于屬性或操作的名字之 前。雖然 UML 指定四種可見性類型，但是實(shí)際的編程語言可能增加額外的可見性，或不支持 UML 定義的可見性。表4顯示了 UML 支持的

6、可見性類型的不同標(biāo)志。            UML 支持的可見性類型的標(biāo)志標(biāo)志可見性類型+Public#proteted-privatepackage5.關(guān)聯(lián)的表示：·雙向（標(biāo)準(zhǔn)）的關(guān)聯(lián)關(guān)聯(lián)是兩個(gè)類間的聯(lián)接。關(guān)聯(lián)總是被假定是雙向的；這意味著，兩個(gè)類彼此知道它們間的聯(lián)系，除非你限定一些其它類型的關(guān)聯(lián)。一個(gè)雙向關(guān)聯(lián)用兩個(gè)類間的實(shí)線表示。在線的任一端，你放置一個(gè)角色名和多重值。圖 6 顯示Flight與一個(gè)特定的Plane相關(guān)聯(lián)，而且Flight類知道這個(gè)關(guān)聯(lián)。因?yàn)榻巧?/p>

7、名以Plane類表示，所以Plane承擔(dān)關(guān)聯(lián)中的 “assignedPlane”角色。緊接于Plane類后面的多重值描述0.1表示，當(dāng)一個(gè)Flight實(shí)體存在時(shí)，可以有一個(gè)或沒有Plane與 之關(guān)聯(lián)（也就是，Plane可能還沒有被分配）。圖 6 也顯示Plane知道它與Flight類的關(guān)聯(lián)。在這個(gè)關(guān)聯(lián)中，F(xiàn)light承擔(dān)“assignedFlights”角色；圖 6 的圖告訴我們，Plane實(shí)體可以不與flight關(guān)聯(lián)（例如，它是一架全新的飛機(jī)）或與沒有上限的flight（例如，一架已經(jīng)服役5年的飛機(jī)）關(guān)聯(lián)。注意：關(guān)聯(lián)的一方關(guān)聯(lián)對(duì)象位于直線的上端，關(guān)聯(lián)數(shù)目位于同側(cè)的直線下端，另一方則相反

8、60;      多重值和它們的表示可能的多重值描述表示含義0.10個(gè)或1個(gè)1只能1個(gè)0.*0個(gè)或多個(gè)*0個(gè)或多個(gè)1.*1個(gè)或多個(gè)3只能3個(gè)0.50到5個(gè)5.155到15個(gè)·單向關(guān)聯(lián)在一個(gè)單向關(guān)聯(lián)中，兩個(gè)類是相關(guān)的，但是只有一個(gè)類知道這種聯(lián)系的存在。一個(gè)單向的關(guān)聯(lián)，表示為一條帶有指向已知類的開放箭頭（不關(guān)閉的箭頭或三角形，用于標(biāo)志繼承）的實(shí)線。如同標(biāo)準(zhǔn)關(guān)聯(lián)，單向關(guān)聯(lián)包括一個(gè)角色名和一個(gè)多重值描述，但是與標(biāo)準(zhǔn)的雙向關(guān)聯(lián)不同的時(shí)，單向關(guān)聯(lián)只包含已知類的角色名和多重值描述。簡單的說就是OverdrawAccountReport中包含了Ban

9、kAccount屬性，而BankAccount中不需要包含OverdrawnAccountsReport對(duì)象6.聚合的表示：聚合是一種特別類型的關(guān)聯(lián)，用于描述“總體到局部”的關(guān)系。在基本的聚合關(guān)系中， 部分類 的生命周期獨(dú)立于 整體類 的生命周期。舉例來說，我們可以想象，車 是一個(gè)整體實(shí)體，而 車輪 輪胎是整輛車的一部分。輪胎可以在安置到車時(shí)的前幾個(gè)星期被制造，并放置于倉庫中。在這個(gè)實(shí)例中，Wheel類實(shí)例清楚地獨(dú)立于Car類實(shí)例而存在。然 而，有些情況下， 部分 類的生命周期并 不 獨(dú)立于 整體 類的生命周期 - 這稱為合成聚合。舉例來說，考慮公司與部門的關(guān)系。 公司和部門 都建模成類，在公

10、司存在之前，部門不能存在。這里Department類的實(shí)例依賴于Company類的實(shí)例而存在。讓我們更進(jìn)一步探討基本聚合和組合聚合。注意：聚合與普通的關(guān)聯(lián)的區(qū)別在于：普通的關(guān)聯(lián)可能只是一個(gè)簡單的“包含、引用”關(guān)系，關(guān)聯(lián)和被關(guān)聯(lián)類之間在邏輯概念上不一定有緊密的聯(lián)系，而聚合則不同，它表示的是一種內(nèi)在關(guān)系緊密，相互依存，相互包含的概念，其中的一部分是構(gòu)成另外一部分的不可或缺的成分。·基本聚合有聚合關(guān)系的關(guān)聯(lián)指出，某個(gè)類是另外某個(gè)類的一部分。在一個(gè)聚合關(guān)系中，子類實(shí)例可以比父類存在更長的時(shí)間。為了表現(xiàn)一個(gè)聚合關(guān)系，你畫一條從父類到部分類的實(shí)線，并在父類的關(guān)聯(lián)末端畫一個(gè)未填充棱形。圖中清楚的表

11、明了類Car對(duì)象包含了另一類Wheel的4個(gè)實(shí)例，這兩者在概念上是密不可分的，其中的一個(gè)類是另一個(gè)類的構(gòu)成成分。菱形表示“包含”，箭頭表示被包含的對(duì)象，數(shù)字4表示包含的數(shù)目。·組合聚合 組合聚合關(guān)系是聚合關(guān)系的另一種形式，但是子類實(shí)例的生命周期依賴于父類實(shí)例的生命周期。注意:組合關(guān)系如聚合關(guān)系一樣繪制，不過這次菱形是被填充的。7.反射關(guān)聯(lián)的表示：類也可以使用反射關(guān)聯(lián)與它本身相關(guān)聯(lián)。起先，這可能沒有意義，但是記住，類是抽象的。當(dāng)一個(gè)類關(guān)聯(lián)到它本身時(shí)，這并不意味著類的實(shí)例與它本身相關(guān)，而是類的一個(gè)實(shí)例與類的另一個(gè)實(shí)例相關(guān)。圖描繪的關(guān)系說明一個(gè)Employee實(shí)例可能是另外一個(gè)E

12、mployee實(shí)例的經(jīng)理。然而，因?yàn)椤癿anages”的關(guān)系角色有 0.*的多重性描述；一個(gè)雇員可能不受任何其他雇員管理。三、UML中的對(duì)象圖：實(shí)例的記號(hào)和類一樣，但是取代頂端區(qū)域中僅有的類名，它的名字是經(jīng)過拼接的:Instance Name : Class Name 如 Donald : Person因?yàn)轱@示實(shí)例的目的是顯示值得注意的或相關(guān)的信息，沒必要在你的模型中包含整個(gè)實(shí)體屬性及操作。相反地，僅僅顯示感興趣的屬性及其值是完全恰當(dāng)?shù)摹?#160;UML 2 也允許在實(shí)體層的關(guān)系/關(guān)聯(lián)建模。繪制關(guān)聯(lián)與一般的類關(guān)系的規(guī)則一樣，除了在建模關(guān)聯(lián)時(shí)有一個(gè)附加的要求。附加的限制是，關(guān)聯(lián)關(guān)系必須與類圖的

13、關(guān)系相一致，而且關(guān)聯(lián)的角色名字也必須與類圖相一致。四、UML中的角色圖：建模類的實(shí)例有時(shí)比期望的更為詳細(xì)。有時(shí)，你可能僅僅想要在一個(gè)較多的一般層次做類關(guān)系的模型。在這種情況下，你應(yīng)該使用 角色 記號(hào)。角色記號(hào)類似于實(shí)例記號(hào)。為了建立類的角色模型，你畫一個(gè)方格，并在內(nèi)部放置類的角色名及類名，作為實(shí)體記號(hào)，但是在這情況你不能加下劃線。注意：角色圖和對(duì)象圖的一個(gè)明顯區(qū)別就是：對(duì)象圖每個(gè)對(duì)象名稱下面都加了下劃線，而角色圖沒有 以下是：序列圖序列圖主要用于按照交互發(fā)生的一系列順序，顯示對(duì)象之間的這些交互。很象類圖，開發(fā)者一般認(rèn)為序列圖只對(duì)他們有意義。然而，一個(gè)組織的業(yè)務(wù)人員

14、會(huì)發(fā) 現(xiàn)，序列圖顯示不同的業(yè)務(wù)對(duì)象如何交互，對(duì)于交流當(dāng)前業(yè)務(wù)如何進(jìn)行很有用。除記錄組織的當(dāng)前事件外，一個(gè)業(yè)務(wù)級(jí)的序列圖能被當(dāng)作一個(gè)需求文件使用，為實(shí)現(xiàn) 一個(gè)未來系統(tǒng)傳遞需求。在項(xiàng)目的需求階段，分析師能通過提供一個(gè)更加正式層次的表達(dá)，把用例帶入下一層次。那種情況下，用例常常被細(xì)化為一個(gè)或者更多的序 列圖。組織的技術(shù)人員能發(fā)現(xiàn)，序列圖在記錄一個(gè)未來系統(tǒng)的行為應(yīng)該如何表現(xiàn)中，非常有用。在設(shè)計(jì)階段，架構(gòu)師和開發(fā)者能使用圖，挖掘出系統(tǒng)對(duì)象間的交互，這樣充實(shí)整個(gè)系統(tǒng)設(shè)計(jì)。 序列圖的主要用途之一，是把用例表達(dá)的需求，轉(zhuǎn)化為進(jìn)一步、更加正式層次的精細(xì)表達(dá)。用例常常被細(xì)化為一個(gè)或者更多的序列圖。序列圖

15、除了在設(shè)計(jì)新 系統(tǒng)方面的用途外，它們還能用來記錄一個(gè)存在系統(tǒng)（稱它為“遺產(chǎn)”）的對(duì)象現(xiàn)在如何交互。當(dāng)把這個(gè)系統(tǒng)移交給另一個(gè)人或組織時(shí)，這個(gè)文檔很有用。Java應(yīng)用程序由許多類所構(gòu)成，是Java實(shí)現(xiàn)面向?qū)ο髴?yīng)用程序的核心。類圖主要描述Java應(yīng)用程序中各種類之間的相互靜態(tài)關(guān)系，如類的繼承、 抽象、接口以及各種關(guān)聯(lián)。要利用UML設(shè)計(jì)Java應(yīng)用程序，僅僅使用類圖來描述這些靜態(tài)關(guān)系，利用可視化工具，要實(shí)現(xiàn)Java應(yīng)用程序的代碼自動(dòng)生成， 是遠(yuǎn)遠(yuǎn)不夠的。我們還必須描述各種類相互之間的協(xié)作關(guān)系、動(dòng)態(tài)關(guān)系，如時(shí)間序列上的交互行為。其中UML序列圖就是用來描述類與類之間的方法調(diào)用過程（或 消息發(fā)送）是如何實(shí)

16、現(xiàn)的。一、UML中的新元素框架：在 UML 2中，框架元件用于作為許多其他的圖元件的一個(gè)基礎(chǔ)，但是大多數(shù)人第一次接觸框架元件的情況，是作為圖的圖形化邊界。當(dāng)為圖提供圖形化邊界時(shí)，一個(gè)框架元件為圖的標(biāo)簽提供一致的位置。在 UML 圖中框架元件是可選擇的。除了提供一個(gè)圖形化邊框之外，用于圖中的框架元件也有描述交互的重要的功能, 例如序列圖。在序列圖上一個(gè)序列接收和發(fā)送消息（又稱交互），能通過連接消息和框架元件邊界，建立模型（如圖 2 所見到）。對(duì)于序列圖，圖的標(biāo)簽由文字“sd”開始。當(dāng)使用一個(gè)框架元件封閉一個(gè)圖時(shí)，圖的標(biāo)簽需要按照以下的格式：圖類型 圖名稱。UML 規(guī)范給圖類型提供特定的文本值。（

17、舉例來說，sd代表序列圖，activity代表活動(dòng)圖，use case代表用例圖）。二、UML中的序列圖：序列圖主要用于按照交互發(fā)生的一系列順序，顯示對(duì)象之間的這些交互。在項(xiàng)目的需求階段，分析師能通過提供一個(gè)更加正式層次的表達(dá)，把用例帶入下一層次。那種情況下，用例常常被細(xì)化為一個(gè)或者更多的序列圖。序列圖的主要用途之一，是把用例表達(dá)的需求，轉(zhuǎn)化為進(jìn)一步、更加正式層次的精細(xì)表達(dá)。用例常常被細(xì)化為一個(gè)或者更多的序列圖。序列圖除了在設(shè)計(jì)新系統(tǒng)方面的用途外，它們還能用來記錄一個(gè)存在系統(tǒng)（稱它為“遺產(chǎn)”）的對(duì)象現(xiàn)在如何交互。序 列圖的主要目的是定義事件序列，產(chǎn)生一些希望的輸出。重點(diǎn)不是消息本身，而是消息產(chǎn)

18、生的順序；不過，大多數(shù)序列圖會(huì)表示一個(gè)系統(tǒng)的對(duì)象之間傳遞的什么消 息，以及它們發(fā)生的順序。圖按照水平和垂直的維度傳遞信息：垂直維度從上而下表示消息/調(diào)用發(fā)生的時(shí)間序列，而且水平維度從左到右表示消息發(fā)送到的對(duì)象實(shí) 例。1.生命線：生命線畫作一個(gè)方格，一條虛線從上而下，通過底部邊界的中心（圖 3）。生命線名字放置在方格里。UML 的生命線命名標(biāo)準(zhǔn)按照如下格式: 實(shí)體名:類名生命線名稱帶下劃線。當(dāng)使用下劃線時(shí)，意味著序列圖中的生命線代表一個(gè)類的特定實(shí)體，不是特定種類的實(shí)體（例如，角色）。序列圖的實(shí)例名稱有下劃線，而角色名稱沒有。一個(gè)生命線能用來表現(xiàn)一個(gè)匿名的或未命名的實(shí)體。當(dāng)在一個(gè)序列圖上

19、，為一個(gè)未命名的實(shí)例建模時(shí)，生命線的名字采用和一個(gè)命名實(shí)例相同的模式；但是生命線名字的位置留下空白，而不是提供一個(gè)例圖名字。2.消息體：為 了顯示一個(gè)對(duì)象（例如，生命線）傳遞一個(gè)消息給另外一個(gè)對(duì)象，你畫一條線指向接收對(duì)象，包括一個(gè)實(shí)心箭頭（如果是一個(gè)同步調(diào)用操作）或一個(gè)棍形箭頭（如果 是一個(gè)異步訊號(hào)）。消息/方法名字放置在帶箭頭的線上面。正在被傳遞給接收對(duì)象的消息，表示接收對(duì)象的類實(shí)現(xiàn)的一個(gè)操作/方法。返回消息是可選擇的；一個(gè)返回消息畫作一個(gè)帶開放箭頭的虛線，向后指向來源的生命線，在這條虛線上面，你放置操作的返回值。為了要畫一個(gè)調(diào)用本身的對(duì)象，如你平時(shí)所作的，畫一條消息，但是不是連接它到另外的

20、一個(gè)對(duì)象，而是你把消息連接回對(duì)象本身。三、UML中的約束：約束的符號(hào)很簡單；格式是: 【Boolean Test】四、UML中的新元素組合碎片（變體方案、選擇項(xiàng)、循環(huán)）：一個(gè)組合碎片用來把一套消息組合在一起，在一個(gè)序列圖中顯示條件分支。1.變體：變體用來指明在兩個(gè)或更多的消息序列之間的、互斥的選擇。一個(gè)變體的組合碎片元件使用框架來畫。單詞“alt”放置在框架的namebox里。然后較大的長方形分為 UML 2 所稱的操作元。 操作元被虛線分開。每個(gè)操作元有一個(gè)約束進(jìn)行測試，而這個(gè)約束被放置在生命線頂端的操作元的左上部。 如果操作元的約束等于“true”，然后那個(gè)操作元是要執(zhí)

21、行的操作元。圖 8作為一個(gè)變體的組合碎片如何閱讀的例子，顯示序列從頂部開始，即bank對(duì)象獲取支票金額和帳戶結(jié)余。此時(shí)，序列圖中的變體組合碎片接管。因?yàn)榧s束 “balance >= amount”，如果余額超過或等于金額，然后順序進(jìn)行bank對(duì)象傳遞 addDebitTransaction 和 storePhotoOfCheck 消息給account對(duì)象。然而，如果余額不是超過或等于金額，然后順序的過程就是bank傳遞addInsuffientFundFee 和 noteReturnedCheck 消息給account對(duì)象，returnCheck 消息給它自身。因?yàn)椤癳lse”約束，當(dāng)余

22、額不大于或者等于金額時(shí)，第二個(gè)序列被調(diào)用。在變體的組合碎片中，不需要“else”約束；而如果一個(gè)操作元， 在它上面沒有一個(gè)明確的約束，那么將假定“else”約束。2.選擇項(xiàng)：一個(gè)選擇項(xiàng)用來為簡單的“if then”表達(dá)式建模。（例如，如果架上的圈餅少于五個(gè)，那么另外做兩打圈餅）。選 擇項(xiàng)組合碎片符號(hào)與變體組合碎片類似，除了它只有一個(gè)操作元并且永不能有“else”約束以外（它就是如此，沒有理由）。要畫選擇項(xiàng)組合，你畫一個(gè)框架。 文字“opt”是被放置在框架的 namebox 里的文本，在框架的內(nèi)容區(qū)，選擇項(xiàng)的約束被放置在生命線頂端上的左上角。 然后選擇項(xiàng)的消息序列被放在框架的內(nèi)容區(qū)的其余位置內(nèi)。

23、注意：變體用于為if then else建模，選擇項(xiàng)用于為if then建模，因?yàn)橹挥幸粋€(gè)分支，所以不能出現(xiàn)else3.循環(huán)：循環(huán)組合碎片表面非常類似選擇項(xiàng)組合碎片。你畫一個(gè)框架，在框架的 namebox 中放置文本“l(fā)oop”。在框架的內(nèi)容區(qū)中，一個(gè)生命線的頂部，循環(huán)約束被 放置在左上角。然后循環(huán)的消息序列被放在框架內(nèi)容區(qū)的其余部分中。在一個(gè)循環(huán)中，除了標(biāo)準(zhǔn)的布爾測試外，一個(gè)約束能測試二個(gè)特定的條件式。特定的約束條件 式是寫作“minint = the number”（例如，“minint = 1”）的最小循環(huán)次數(shù)，或?qū)懽鳌癿axint = the number”（例如，“maxint =

24、5”）的最大循環(huán)次數(shù)。通過最小循環(huán)檢驗(yàn)，循環(huán)必須運(yùn)行至少指定次數(shù)，而循環(huán)執(zhí)行次數(shù)不能達(dá)到約束指定的最大循環(huán)次數(shù)。以下是：用例圖：用例圖主要用來圖示化系統(tǒng)的主事件流程，它主要用來描述客戶的需求，即 用戶希望系統(tǒng)具備的完成一定功能的動(dòng)作，通俗地理解用例就是軟件的功能模塊，所以是設(shè)計(jì)系統(tǒng)分析階段的起點(diǎn)，設(shè)計(jì)人員根據(jù)客戶的需求來創(chuàng)建和解釋用例圖， 用來描述軟件應(yīng)具備哪些功能模塊以及這些模塊之間的調(diào)用關(guān)系，用例圖包含了用例和參與者，用例之間用關(guān)聯(lián)來連接以求把系統(tǒng)的整個(gè)結(jié)構(gòu)和功能反映給非技術(shù)人 員（通常是軟件的用戶），對(duì)應(yīng)的是軟件的結(jié)構(gòu)和功能分解。用例是從系統(tǒng)外部可見的行為，是系統(tǒng)為某一個(gè)或幾個(gè)參與者（A

25、ctor）提供的一段完整的服務(wù)。從原則上來講，用例之間都是獨(dú)立、并列的，它們之間并不存 在著包含從屬關(guān)系。但是為了體現(xiàn)一些用例之間的業(yè)務(wù)關(guān)系，提高可維護(hù)性和一致性，用例之間可以抽象出包含(include)、擴(kuò)展(extend)和泛 (generalization)幾種關(guān)系。共性：都是從現(xiàn)有的用例中抽取出公共的那部分信息，作為一個(gè)單獨(dú)的用例，然后通后過不同的方法來重用這個(gè)公共的用例，以減少模型維護(hù)的工作量。 1、包含(include)     包含關(guān)系：使用包含（Inclusion）用例來封裝一組跨越多個(gè)用例的相似動(dòng)作（行為片斷），以便多個(gè)基（B

26、ase）用例復(fù)用。基用例控制與包含用例的 關(guān)系，以及被包含用例的事件流是否會(huì)插入到基用例的事件流中?；美梢砸蕾嚢美龍?zhí)行的結(jié)果，但是雙方都不能訪問對(duì)方的屬性。    包含關(guān)系對(duì)典型的應(yīng)用就是復(fù)用，也就是定義中說的情景。但是有時(shí)當(dāng)某用例的事件流過于復(fù)雜時(shí)，為了簡化用例的描述，我們也可以把某一段事件流抽象成為一個(gè)被包含的用例；相反，用例劃分太細(xì)時(shí)，也可以抽象出一個(gè)基用例，來包含這些細(xì)顆粒的用例。這種情況類似于在過程設(shè)計(jì)語言中，將程序的某一段算法封裝成一個(gè)子過程，然后再從主程序中調(diào)用這一子過程。   例如：業(yè)務(wù)中，總是存在著維護(hù)某某信息的功能，

27、如果將它作為一個(gè)用例，那新建、編輯以及修改都要在用例詳述中描述，過于復(fù)雜；如果分成新建用例、編輯用例和刪除用例，則劃分太細(xì)。這時(shí)包含關(guān)系可以用來理清關(guān)系。2、擴(kuò)展(extend)擴(kuò)展關(guān)系：將基用例中一段相對(duì)獨(dú)立并且可選的動(dòng)作，用擴(kuò)展（Extension）用例加以封裝，再讓它從基用例中聲明的擴(kuò)展點(diǎn)（Extension Point）上進(jìn)行擴(kuò)展，從而使基用例行為更簡練和目標(biāo)更集中。擴(kuò)展用例為基用例添加新的行為。擴(kuò)展用例可以訪問基用例的屬性，因此它能根據(jù)基用例中擴(kuò)展 點(diǎn)的當(dāng)前狀態(tài)來判斷是否執(zhí)行自己。但是擴(kuò)展用例對(duì)基用例不可見。對(duì)于一個(gè)擴(kuò)展用例，可以在基用例上有幾個(gè)擴(kuò)展點(diǎn)。  

28、60;例如，系統(tǒng)中允許用戶對(duì)查詢的結(jié)果進(jìn)行導(dǎo)出、打印。對(duì)于查詢而言，能不能導(dǎo)出、打印查詢都是一樣的，導(dǎo)出、打印是不可見的。導(dǎo)入、打印和查詢相對(duì)獨(dú)立，而且為查詢添加了新行為。因此可以采用擴(kuò)展關(guān)系來描述：4、泛化(generalization) 泛化關(guān)系：子用例和父用例相似，但表現(xiàn)出更特別的行為；子用例將繼承父用例的所有結(jié)構(gòu)、行為和關(guān)系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。在實(shí)際應(yīng)用中很少使用泛化關(guān)系，子用例中的特殊行為都可以作為父用例中的備選流存在。例如，業(yè)務(wù)中可能存在許多需要部門領(lǐng)導(dǎo)審批的事情，但是領(lǐng)導(dǎo)審批的流程是很相似的，這時(shí)可以做成泛化關(guān)系表示：&#

29、160;    上面是我參考的一篇文章，覺得將三種關(guān)系的區(qū)別講得很清晰，在此基礎(chǔ)上結(jié)合自己的系統(tǒng)，對(duì)項(xiàng)目(在線購物系統(tǒng))的用例做了整體的描繪。    *    (1)系統(tǒng)整體用例圖           (商品用例圖)                &

30、#160;  （購買信息用例）            (用戶資料用例)         按照先整體用例，后子系統(tǒng)用例來進(jìn)行描繪的，歡迎大家提出好的建議!轉(zhuǎn)：UML中擴(kuò)展和泛化的區(qū)別          泛化表示類似于OO術(shù)語“繼承”或“多態(tài)”。UML中的Use Case泛化過程是將不同Use Case

31、之間的可合并部分抽象成獨(dú)立的父Use Case，并將不可合并部分單獨(dú)成各自的子Use Case；包含以及擴(kuò)展過程與泛化過程類似，但三者對(duì)用例關(guān)系的優(yōu)化側(cè)重點(diǎn)是不同的。如下：          泛化側(cè)重表示子用例間的互斥性；          包含側(cè)重表示被包含用例對(duì)Actor提供服務(wù)的間接性；          擴(kuò)展側(cè)重表示擴(kuò)展

32、用例的觸發(fā)不定性；詳述如下：        既然用例是系統(tǒng)提供服務(wù)的UML表述，那么服務(wù)這個(gè)過程在所有用例場景中是必然發(fā)生的，但發(fā)生按照發(fā)生條件可分為如下兩種情況：         無條件發(fā)生：肯定發(fā)生的；         有條件發(fā)生：未必發(fā)生，發(fā)生與否取決于系統(tǒng)狀態(tài)；         因

33、此，針對(duì)用例的三種關(guān)系結(jié)合系統(tǒng)狀態(tài)考慮，泛化與包含用例屬于無條件發(fā)生的用例，而擴(kuò)展屬于有條件發(fā)生的用例。進(jìn)一步，用例的存在是為Actor提供服 務(wù)，但用例提供服務(wù)的方式可分為間接和直接兩種，依據(jù)于此，泛化中的子用例提供的是直接服務(wù)，而包含中的被包含用例提供的是間接服務(wù)。同樣，擴(kuò)展用例提供 的也是直接服務(wù)，但擴(kuò)展用例的發(fā)生是有條件的。         另外一點(diǎn)需要提及的是：泛化中的子用例和擴(kuò)展中的擴(kuò)展用例均可以作為基本用例事件的備選擇流而存在。 以下是：活動(dòng)圖UML 活動(dòng)圖記錄了單個(gè)操作或方法的邏輯，單個(gè)用

34、戶案例，或者單個(gè)業(yè)務(wù)流程的邏輯。在很多方面，活動(dòng)圖是結(jié)構(gòu)化開發(fā)中流程圖和數(shù)據(jù)流程圖 (DFD) 的面向?qū)ο蟮韧w,要?jiǎng)?chuàng)建一個(gè) UML 活動(dòng)圖，您需要反復(fù)執(zhí)行下列步驟。第一步，定義活動(dòng)圖的范圍首先應(yīng)該定義您要對(duì)什么建模。單個(gè)用戶案例力？一個(gè)用戶案例的一部分？一個(gè)包含多個(gè)用戶案例的商務(wù)流程？一個(gè)類的單個(gè)方法？一旦 您定義了您所作圖的范圍，您應(yīng)該在其頂部，用一個(gè)標(biāo)注添加標(biāo)簽，指明該圖的標(biāo)題和唯一的標(biāo)示符。您有可能也想要包括該圖的時(shí)間甚至作者名。     第二步，添加起始和結(jié)束點(diǎn)每個(gè)活動(dòng)圖有一個(gè)起始點(diǎn)和結(jié)束點(diǎn)，因此您也要馬上添加它們。在 UML 精粹(UML D

35、istilled) (參見參考資料)，F(xiàn)owler 和 Scott 認(rèn)為結(jié)束點(diǎn)是可選的。有時(shí)候一個(gè)活動(dòng)只是一個(gè)簡單的結(jié)束，如果是這種情況，指明其唯一的轉(zhuǎn)變是到一個(gè)結(jié)束點(diǎn)也是無害的。這樣，當(dāng)其他人閱讀您的圖時(shí)，他或 她知道您已經(jīng)考慮了如何退出這些活動(dòng)。第三步，添加活動(dòng)如果您正對(duì)一個(gè)用戶案例建模，對(duì)每個(gè)角色(actor)所發(fā)出的主要步驟引入一個(gè)活動(dòng)(該活動(dòng)可能包括起始步驟，加上對(duì)起始步驟系統(tǒng)響應(yīng) 的任何步驟)。如果您正對(duì)一個(gè)高層的商務(wù)流程建模，對(duì)每個(gè)主要流程引入一個(gè)活動(dòng)，通常為一個(gè)用戶案例或用戶案例包。最后，如果您正對(duì)一個(gè)方法建模，那么對(duì) 此引入一個(gè)活動(dòng)是很常見的。 第四步，添加活動(dòng)間的

36、轉(zhuǎn)變我的風(fēng)格總是應(yīng)該退出一個(gè)活動(dòng)，即使它是轉(zhuǎn)變到一個(gè)結(jié)束點(diǎn)。一旦一個(gè)活動(dòng)有多個(gè)轉(zhuǎn)變時(shí)，您必需對(duì)每個(gè)轉(zhuǎn)變加以相應(yīng)標(biāo)示。第五步，添加決策點(diǎn)有時(shí)候，您所建模的邏輯需要做出一個(gè)決策。有可能是需要檢查某些事務(wù)或比較某些事務(wù)。要注意的是，使用決策點(diǎn)是可選的。第六步，找出可并行活動(dòng)之處當(dāng)兩個(gè)活動(dòng)間沒有直接的聯(lián)系，而且它們都必需在第三個(gè)活動(dòng)開始前結(jié)束，那它們是可以并行運(yùn)行的。     下面的活動(dòng)圖描述了大學(xué)新生第一次將如何辦理入學(xué)的商業(yè)邏輯。· 實(shí)心圓表示活動(dòng)圖的起點(diǎn)，實(shí)際上是一個(gè)占位符，帶邊框的實(shí)心圓表示終點(diǎn)。· 圓角矩形表示執(zhí)行的過程或

37、活動(dòng)。在該圖中，雖然您會(huì)注意到“登記研習(xí)班”用例將多次調(diào)用“登記研習(xí)班”活動(dòng)，但這些活動(dòng)卻相當(dāng)緊密地映射到用例?；顒?dòng)可以細(xì)致得多，特別在選擇記錄方法邏輯，而不是高級(jí)商業(yè)過程時(shí)。· 菱形表示判定點(diǎn)，雖然在此示例中判定點(diǎn)只有兩種可能結(jié)果；但即使有更多可能結(jié)果，它也同樣容易。· 箭頭表示活動(dòng)之間的轉(zhuǎn)換，各種活動(dòng)之間的流動(dòng)次序。· 箭頭上的文字表示繼續(xù)轉(zhuǎn)換所必須滿足的條件，總是使用格式“條件”來描述。我猜想，在 UML 的將來版本中，我們將會(huì)看到使用 UML 約束表示法（如“condition”）記錄的條件。· 粗線條表示

38、可能會(huì)并行進(jìn)行的過程的開始和結(jié)束；在大學(xué)里成功入學(xué)后，必須參加指定的概況介紹，還要至少登記一個(gè)研習(xí)班并交付一部分的學(xué)費(fèi)。 退出活動(dòng)可能有幾種方法，如您看到的“填寫入學(xué)表”活動(dòng)的那樣。如果正確填寫了表格，那么可以繼續(xù)進(jìn)行大學(xué)的入學(xué)手續(xù)。但是，如果表格不正確，那么必須獲得幫助（可能從注冊員獲得幫助）以正確填寫它們。圖 1. 第一次入學(xué)的 UML 活動(dòng)圖這個(gè)活動(dòng)圖非常有趣，因?yàn)樗〉袅藞D 2 中標(biāo)識(shí)的幾個(gè)用例的邏輯。用例模型沒有很好地表達(dá)處理的順序是件好事。例如，雖然圖 2 中顯示的用例圖為您清楚地描述了該系統(tǒng)所執(zhí)行的功能類型，但是它沒有明確地表達(dá)這

39、些用例可能發(fā)生的順序。但是，圖 1 的活動(dòng)圖做到了這一點(diǎn)?？傊?，不同模型的優(yōu)缺點(diǎn)各有不同。中標(biāo)識(shí)的幾個(gè)用例的邏輯。用例模型沒有很好地表達(dá)處理的順序是件好事。例如，雖然 中顯示的用例圖為您清楚地描述了該系統(tǒng)所執(zhí)行的功能類型，但是它沒有明確地表達(dá)這些用例可能發(fā)生的順序。但是， 的活動(dòng)圖做到了這一點(diǎn)?？傊?，不同模型的優(yōu)缺點(diǎn)各有不同。圖 2. 大學(xué)的用例圖 泳道 將模型中的活動(dòng)按照職責(zé)組織起來通常很有用。例如，可以將一個(gè)商業(yè)組織處理的所有活動(dòng)組織起來。這種分配可以通過將活動(dòng)組織成用線分開的不同區(qū)域來表示。由于它們的外觀的緣故，這些區(qū)域被稱作泳道。 圖 72 表示了泳道。圖 72 泳道和對(duì)象流· 2.