用例之間的關(guān)系

1、-作者xxxx-日期xxxx用例之間的關(guān)系【精品文檔】用例之間的關(guān)系1、 泛化關(guān)系Generalization代表一般與特殊的關(guān)系。（類似于繼承）在用例泛化中，子用例表示父用例的特殊形式，子用例繼承了父用例的行為和屬性，也可以增加新的行為和屬性或覆蓋父用例中的行為。例子：一個租賃或銷售系統(tǒng)用例的部分內(nèi)容，在此，父用例是“預(yù)定”，其兩個子用例分別是“網(wǎng)上預(yù)定”和“電話預(yù)定”，這兩個用例都繼承了父用例的行為，并可以添加自己的行為。2、 包含關(guān)系Include一個用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行為，并把它所包含的用例行為作為自身用例的一部分，這被稱為包含關(guān)系。在UML中，

2、包含關(guān)系表示為虛線箭頭加版型include，箭頭從基本用例指向包含用例。例子：一個租賃或銷售系統(tǒng)中，“填寫電子表格”的功能在“網(wǎng)上預(yù)定”的過程中使用，不管如何處理“網(wǎng)上預(yù)定”用例，總是要運(yùn)行“填寫電子表格”用例，因此具有包含關(guān)系。3、 擴(kuò)展關(guān)系Extend一個用例也可以定義為基本用例的增量擴(kuò)展，這稱作擴(kuò)展關(guān)系，即擴(kuò)展關(guān)系是把新的行為插入到已有的用例中的方法。在UML中，包含關(guān)系表示為虛線箭頭加版型extend，箭頭從擴(kuò)展用例指向基本用例?；居美峁┝艘唤M擴(kuò)展點(diǎn)，在這些新的擴(kuò)展點(diǎn)中可以添加新的行為，而擴(kuò)展用例提供了一組插入片段，這些片段能夠被插入到基本用例的擴(kuò)展點(diǎn)上。擴(kuò)展關(guān)系可以有控制條件，當(dāng)

3、用例實例執(zhí)行到達(dá)一個擴(kuò)展點(diǎn)時，控制條件決定是否執(zhí)行擴(kuò)展。一般情況下，基本用例的執(zhí)行不會涉及到擴(kuò)展用例，只有滿足用例的控制條件時，擴(kuò)展用例才被執(zhí)行，因此擴(kuò)展關(guān)系處理事件流的異?；蛘呖蛇x事件。同一個基本用例的幾個擴(kuò)展可以在一起使用?；居美恢罃U(kuò)展的任何細(xì)節(jié).沒有擴(kuò)展用例,基本用例是完整的。例子：一個汽車租賃系統(tǒng)用例圖的部分內(nèi)容。在此，基本用例是“還車”，擴(kuò)展用例是“交納罰金”。如果一切順利汽車可以被歸還，那么執(zhí)行“還車”用例即可。但是如果超過了還車的時間或汽車受損，按照規(guī)定客戶要交納一定的罰金，這時就不能執(zhí)行提供的常規(guī)動作。若研討修改用例“還車”，勢必會增加系統(tǒng)的復(fù)雜性，因此可以在用例“還車”

4、中增加擴(kuò)展點(diǎn)，即特定條件為超時或損壞，如果滿足條件，將執(zhí)行擴(kuò)展用例“交納罰金”，這樣顯然可以使系統(tǒng)更容易被理解。4、 參與者與用例之間的關(guān)系：關(guān)聯(lián)關(guān)系A(chǔ)ssociation關(guān)聯(lián)關(guān)系描述參與者與用例之間的關(guān)系，在UML中它是兩個或多個類元之間的關(guān)系，它描述了類元的實例間的聯(lián)系。（類元，一種建模元素，常見類元包括類、參與者、構(gòu)件、數(shù)據(jù)類型、接口、結(jié)點(diǎn)、信號、子系統(tǒng)以及用例等，其中類是最常見的類元。）關(guān)聯(lián)關(guān)系表示參與者和用例之間的通信。在UML中，關(guān)聯(lián)關(guān)系用直線或箭頭表示。關(guān)聯(lián)中communicates版型是參與者和用例之間唯一的版型,一般省略不寫。如果參與者啟動了用例，箭頭指向用例；如果參與者利用

5、了用例提供的服務(wù),箭頭指向參與者。如果二者是互動的，則是直線。關(guān)聯(lián)關(guān)系表示參與者和用例之間的通信。不同的參與者可以訪問相同的用例，一般說來它們和該用例的交互是不一樣的，如果一樣的話，說明他們的角色可能是相同的。如果兩種交互的目的也相同，說明他們的角色是相同的，就應(yīng)該將他們合并。例子：一個汽車租賃系統(tǒng)用例圖的部分內(nèi)容。這個例子顯示的是“客戶”參與者以及與他交互的3個用例，“預(yù)定”、“取車”、“還車”?！翱蛻簟笨梢詥舆@3個用例。1、閱讀用例圖用例圖是顯示處于同一系統(tǒng)中的參與者和用例之間的關(guān)系的圖。一個用例圖是一個包括參與者、由系統(tǒng)邊界封閉的一組用例、參與者和用例之間的關(guān)聯(lián)、用例間的聯(lián)系以及參與者

6、的泛化等模型元素的圖。例子：棋牌館管理系統(tǒng)用例模型局部 系統(tǒng)主要功能：以internet的形式向客戶提供座位預(yù)定的服務(wù)，并且如果暫時無法獲取座位的餓信息，允許客戶進(jìn)入“等候隊列”，當(dāng)有人退訂之后及時通知客戶。另外，該系統(tǒng)還將為總臺服務(wù)員提供作座位安排以及結(jié)賬的功能，要求能夠支持現(xiàn)金和銀行卡兩種結(jié)賬方式。(1) 系統(tǒng)邊界圖中有4種元素：參與者、用例、一個方框和一些表示關(guān)系的連接線。其中，參與者有3個，分別是客戶、總臺服務(wù)員、和銀聯(lián)POS系統(tǒng)，還包括預(yù)定座位、安排座位、辦理結(jié)賬等8個用例。圖中有一個方框，所有的用例都在這個方框內(nèi)，并且它還有一個名字：棋牌館管理系統(tǒng)。在UML表示法中，這個方框稱為“

7、系統(tǒng)邊界”，或者“系統(tǒng)范圍”，它用來定義系統(tǒng)的界限，系統(tǒng)用例都置于其中，參與者則在邊界之外。通過這個系統(tǒng)邊界可以很清晰的表述出正在開發(fā)的系統(tǒng)的范圍。例如，圖中明確的指出了該系統(tǒng)在處理銀行卡結(jié)賬時將通過系統(tǒng)外的“銀聯(lián)系統(tǒng)”來完成，銀聯(lián)系統(tǒng)是位于系統(tǒng)外的。(2) 參與者與用例之間的關(guān)系 一個參與者表示用例的使用者在與這些用例進(jìn)行交互時所扮演的角色。如：當(dāng)通過Internet預(yù)定座位時，這些系統(tǒng)的使用者就是棋牌館的客戶，而只有“總臺服務(wù)員”具有安排座位和結(jié)賬的操作權(quán)限。(3) 用例之間的關(guān)系用例之間的包含和擴(kuò)展關(guān)系是分解和組織用例的有效工具。一個用例是一個事件流的集合（包括基本事件流、擴(kuò)展事件流等）

8、，而包含和擴(kuò)展表示的跨用例間的事件流是不一樣的?；臼录鳎菏菍τ美谐Ｒ?guī)、預(yù)期路徑的描述，這是大部分時間所遇到的場景，它體現(xiàn)了系統(tǒng)的核心價值。擴(kuò)展事件流：主要是對一些異常情況、選擇分支進(jìn)行描述。 包含關(guān)系：指基用例在它的內(nèi)部說明的某個位置上顯式的合并了另一個用例的行為。在棋牌館用例圖中，用例預(yù)定座位就包含了用例檢查座位信息?？梢栽O(shè)想，當(dāng)客戶預(yù)定座位時，當(dāng)然需要知道座位的信息（是否有空座位，有哪些空座位），因此這兩個用例的事件流執(zhí)行順序如下圖。也就是說，被包含的用例（此例中的檢查座位詳情）不是孤立存在的，它僅作為某些包含它的更大的基用例（此例中的預(yù)訂座位、安排座位）的一部分出現(xiàn)。也只有當(dāng)某個事

9、件流片段在多個用例中出現(xiàn)的時候（本例中，在客戶預(yù)定座位和總臺服務(wù)員安排座位時都需要檢查座位的詳情），才將這個事件流片段抽取出來，放在一個單獨(dú)的用例中，這樣就可以簡化基本用例的事件流描述，同時也使得整個系統(tǒng)的描述更加清晰。 擴(kuò)展關(guān)系：指基用例在由擴(kuò)展用例間接說明的一個位置上隱式的合并了另一個用例的行為。在棋牌館用例圖中，用例處理等候隊列就是對用例預(yù)定座位的一個擴(kuò)展?？梢栽O(shè)想，當(dāng)客戶預(yù)定座位時，如果沒有空座位或者客戶想要的座位時，客戶就有兩種選擇：一是取消預(yù)定操作，二是進(jìn)入等侯隊列，等系統(tǒng)通知；如果有客戶想要的座位，就無需進(jìn)入等候隊列了。也就是說，用例處理等候隊列中的事件流并不是在每次預(yù)定座位的時

10、候都會發(fā)生。因此這兩個用例的事件流執(zhí)行順序如下圖。 所以說，基本用例是可以獨(dú)立于擴(kuò)展用例存在的，只是在特定的條件下，它的行為可以被另一個用例的行為所擴(kuò)展。在實際建模中，只有對那些表示用戶看作可選的系統(tǒng)行為的用例才使用擴(kuò)展關(guān)系來建模。通過這種方式，可以把可選行為從必須的行為中分離出來。 泛化關(guān)系：在用例圖中引入泛化關(guān)系。對于參與者而言，泛化關(guān)系的引用可有效降低模型的復(fù)雜度。如在棋牌館用例圖中，我們可以引入“迎賓員”的角色，并且為了緩解總臺壓力，希望讓迎賓員也能完成“安排座位”的職責(zé)，那么可以通過參與泛化來更有效的組織這個用例圖。下圖表述了：總臺服務(wù)員是一種“特殊”的迎賓員，他不僅可以安排座位，還

11、能夠辦理結(jié)賬。 用例之間的泛化則表示子用例繼承了父用例的行為和含義；子用例還可以增加或覆蓋父用例的行為，更可以出現(xiàn)在父用例出現(xiàn)的任何位置。如：在棋牌館用例圖中，用例收款只定義了收款的一般過程，而處理現(xiàn)金結(jié)賬和處理銀行卡結(jié)賬則是兩個子用例，他們完成不同情況下的收款工作。如圖(4) 讀圖小結(jié)通過以上幾部分的講解，不難得出棋牌館用例圖所表示的含義。這張用例圖首先定義了三個基本用例：預(yù)訂座位、安排座位和處理結(jié)賬。 l 客戶通過Internet啟動“預(yù)訂座位”用例，在“預(yù)訂座位”用例的執(zhí)行過程中，將“檢查座位信息”（被包含用例），如果沒有空閑的座位或滿意的座位，可以選擇進(jìn)入等候隊列，這樣就將啟動擴(kuò)展用例

12、“處理等候隊列”。l 總臺服務(wù)員在客戶到棋牌館時，啟動“安排座位”用例，在執(zhí)行過程中，將啟動被包含用例“檢查座位信息”。l 當(dāng)客戶要離開棋牌館時，總臺服務(wù)員將啟動“處理結(jié)賬”用例，并且定義了兩種“收款”用例，一個是“處理現(xiàn)金結(jié)賬”，另一個是“處理銀行卡結(jié)賬”，而后一個用例將通過與外部系統(tǒng)“銀聯(lián)POS系統(tǒng)”交互來完成。正如前面的例子所示，只有棋牌館用例圖（棋牌館管理系統(tǒng)用例模型局部），很多細(xì)節(jié)信息都沒有明確的表示出來，只是勾勒了一個大致的系統(tǒng)功能輪廓，這樣對于軟件開發(fā)活動是不夠充分的。一個完整的用例模型不僅包括用例圖，更重要的是它的用例描述部分，它是后續(xù)交互圖分析和類圖分析不可缺少的部分。用例描

13、述的是一個系統(tǒng)做什么（what）的信息（即功能需求），并不說明怎么做（how），怎么做是設(shè)計模型的事。（1）一般來說，用例描述采用自然語言描述參與者與系統(tǒng)進(jìn)行交互時的行為。它一般包括以下內(nèi)容： 用例的目標(biāo) 用例是怎么啟動的 參與者和用例之間的消息是如何傳送的 用例中除了主路徑，其他路徑是什么 用例結(jié)束后的系統(tǒng)狀態(tài) 其他需要描述的內(nèi)容（2）用例描述的格式（用例模板）用例編號為用例制定一個唯一的編號，通常格式為UCxx用例名稱應(yīng)為一個動詞短語，讓讀者一目了然地知道用例的目標(biāo)用例概述用例的目標(biāo)，一個概要性的描述范圍用例的設(shè)計范圍主參與者該用例的主Actor，在此列出名稱，并簡要的描述它次要參與者該用

14、例的次要Actor，在此列出名稱，并簡要的描述它項目相關(guān)人利益說明項目相關(guān)人利益項目相關(guān)人員名稱從該用例獲取的利益前置條件即啟動該用例所應(yīng)該滿足的條件。后置條件即該用例完成之后，將執(zhí)行什么動作。成功保證描述當(dāng)前目標(biāo)完成后，環(huán)境變化情況?；臼录鞑襟E活動1在這里寫出觸發(fā)事件到目標(biāo)完成以及清除的步驟。2(其中可以包含子事件流，以子事件流編號來表示)擴(kuò)展事件流1a1a表示是對1的擴(kuò)展，其中應(yīng)說明條件和活動1b(其中可以包含子事件流，以子事件流編號來表示)子事件流對多次重復(fù)的事件流可以定義為子事件流，這也是抽取被包含用例的地方。規(guī)則與約束對該用例實現(xiàn)時需要考慮的業(yè)務(wù)規(guī)則、非功能需求、設(shè)計約束等注：表

15、格中加粗是必須編寫部分例子：四種常見的錯誤：P31 種錯誤和修改。編寫要點(diǎn)：（1）使用簡單的語法：主語明確，語義易于理解，能清晰表述動作即可；（2）明確寫出“誰控制球”：也就是在事件流描述中，讓讀者直觀地了解是參與者在控制還是系統(tǒng)在控制；（3）從俯視的角度來編寫：指出參與者的動作，以及系統(tǒng)的響應(yīng)，也就是從第三者觀察的角度；（4）顯示過程向前推移：也就是每一步都有前進(jìn)的感（例如，用戶按下tab鍵作為一個事件就是不合適的）；如果過程繁雜，超過了9步，那么考慮提高目標(biāo)層次，即“向前推移”（5）顯示參與者的意圖而非動作（如果只描述了動作，人們不能夠很容易地直接從事件流描述中理解用例）；通過操縱系統(tǒng)的用

16、戶界面來描述用戶的動作，這是在編寫用例時常見的一種嚴(yán)重錯誤，它使得編寫的目標(biāo)處于一個很低的層次，叫做“界面細(xì)節(jié)描述（interface detail description）”。在需求文檔中，我們只關(guān)心界面所要達(dá)到的意圖，總結(jié)在執(zhí)行者之間傳遞的信息?？蓪⑦@些低層次的步驟合并成一個步驟。1、用例分析技術(shù)步驟（不固定，可根據(jù)需要調(diào)整）： 找出系統(tǒng)外部的參與者和外部系統(tǒng)，確定系統(tǒng)的邊界和范圍。 確定每一個參與者所期望的系統(tǒng)行為 把這些系統(tǒng)行為命名為用例 使用泛化、包含、擴(kuò)展等關(guān)系處理系統(tǒng)行為的公共或變更部分 編制每一個用例的腳本 繪制用例圖 區(qū)分基本事件流和異常情況的事件流，如有需要可以把表示異常情

17、況的事件流作為單獨(dú)的用例來處理 細(xì)化用例圖，解決用例間的重復(fù)與沖突。2、簡例：課表查詢系統(tǒng)（1）教師、學(xué)生、教務(wù)管理人員、輔導(dǎo)員等等。（2）教師、學(xué)生可以查詢自己的課表；教務(wù)管理人員可以管理和維護(hù)課表（增、刪、改、打印報表等）（3）命名（4）查詢實現(xiàn)不同，包含關(guān)系：人的出現(xiàn)、數(shù)據(jù)庫的出現(xiàn)、登錄（5）（6） （7）登錄錯誤3、詳細(xì)例子：個人圖書管理系統(tǒng) 用例圖的繪制流程 記錄需求特性表編號說明FEAT01新增書籍信息 FEAT02修改已有的書籍信息 FEAT03書籍信息按計算機(jī)類、非計算機(jī)類分別建檔 FEAT04錄入新書時能夠自動按規(guī)則生成書號FEAT05計算機(jī)類與非計算機(jī)類書籍采用不同的書號規(guī)

18、則FEAT06錄入新書時如果重名將自動提示FEAT07按書名、作者、類別、出版社等關(guān)鍵字組合查詢書籍FEAT08列出所有書籍信息FEAT09記錄外借情況FEAT10外借狀態(tài)能夠自動反應(yīng)在書籍信息中FEAT11按人、按書查詢外借情況FEAT12列出所有的外借情況FEAT13按特定時間段統(tǒng)計購買金額、冊數(shù)FEAT14所有查詢、列表、統(tǒng)計功能應(yīng)可以單獨(dú)對計算機(jī)類或非計算機(jī)類進(jìn)行 識別參與者·使用系統(tǒng)主要功能的人是誰？·系統(tǒng)可以幫助誰？·維護(hù)、管理系統(tǒng)的人是誰？·系統(tǒng)能夠控制的硬件有？·對系統(tǒng)的結(jié)構(gòu)感興趣的人或事物？·系統(tǒng)使用哪些軟件系統(tǒng)，和

19、被哪些軟件系統(tǒng)使用？ 合并需求獲得用例特性用例FEAT01.新增書籍信息FEAT03.書籍信息按計算機(jī)類、非計算機(jī)類分別建檔FEAT04.錄入新書時能夠自動按規(guī)則生成書號FEAT05.計算機(jī)類與非計算機(jī)類書籍采用不同的書號規(guī)則FEAT06.錄入新書時如果重名將自動提示UC01.新增書籍信息FEAT02.修改已有的書籍信息UC02.修改書籍信息FEAT07.按書名、作者、類別、出版社等關(guān)鍵字組合查詢書籍FEAT08.列出所有書籍信息FEAT14.所有查詢、列表、統(tǒng)計功能應(yīng)可以單獨(dú)對計算機(jī)類或非計算機(jī)類進(jìn)行UC03.查詢書籍信息FEAT09.記錄外借情況FEAT10.外借狀態(tài)能夠自動反應(yīng)在書籍信息

20、中UC04.登記外借信息FEAT11.按人、按書查詢外借情況FEAT12.列出所有的外借情況FEAT14.所有查詢、列表、統(tǒng)計功能應(yīng)可以單獨(dú)對計算機(jī)類或非計算機(jī)類進(jìn)行UC05.查詢外借信息FEAT13.按特定時間段統(tǒng)計購買金額、冊數(shù)FEAT14.所有查詢、列表、統(tǒng)計功能應(yīng)可以單獨(dú)對計算機(jī)類或非計算機(jī)類進(jìn)行UC06.統(tǒng)計金額和冊數(shù) 繪制用例圖 細(xì)化用例描述A搭框架1.用例名稱：新增書籍信息（UC01）2.簡要說明：錄入新購書籍信息，并自動存儲建檔。3.事件流： 3.1 基本事件流 3.2 擴(kuò)展事件流5.前置條件：用戶進(jìn)入圖書管理系統(tǒng)。6.后置條件：完成新書信息的存儲建檔。7.擴(kuò)展點(diǎn)：無8.優(yōu)先級

21、：最高（滿意度 5，不滿意度5） 細(xì)化用例描述B填血肉3.事件流： 3.1 基本事件流 1）圖書管理員向系統(tǒng)發(fā)出“新增書籍信息”請求； 2）系統(tǒng)要求圖書管理員選擇要新增的書籍是計算機(jī)類還 是非計算機(jī)類； 3）圖書管理員做出選擇后，顯示相應(yīng)界面，讓圖書管理 員輸入信息，并自動根據(jù)書號規(guī)則生成書號； 4）圖書管理員輸入書籍的相關(guān)信息，包括：書名、作者、 出版社、ISBN號、開本、頁數(shù)、定價、是否有CDROM； 5）系統(tǒng)確認(rèn)輸入的信息中書名未有重名； 6）系統(tǒng)將所輸入的信息存儲建檔。 3.2 擴(kuò)展事件流 5a）如果輸入的書名有重名現(xiàn)象，則顯示出重名 的書籍，并要求圖書管理選擇修改書名或取消輸入； 5

22、a1）圖書管理員選擇取消輸入，則結(jié)束用例，不做存儲建檔工作； 5a2）圖書管理員選擇修改書名后，轉(zhuǎn)到5）4.非功能需求：無特殊要求4、尋找用例的方法（1）啟發(fā)性原則：P34Ø 和用戶交互Ø 把自己當(dāng)作參與者,與設(shè)想中的系統(tǒng)進(jìn)行交互Ø 確定用例和確定參與者不能截然分開（2）尋找用例的啟發(fā)式問題：P35 啟發(fā)式問題是針對每一個參與者的。參與者為什么要使用該系統(tǒng)？ 參與者是否會在系統(tǒng)中創(chuàng)建、修改、刪除、訪問、存儲數(shù)據(jù)？如果是的話，參與者又是如何來完成這些操作的？ 參與者是否會將外部的某些事件通知給該系統(tǒng)？ 系統(tǒng)是否會將內(nèi)部的某些事件通知該參與者？3.8 常見問題分析問題

23、：在一個系統(tǒng)中，有幾個相似的功能，那么將他們放在同一個用例中，還是分成幾個用例？假設(shè)有這樣的需求，在學(xué)生檔案管理中，管理員經(jīng)常要做3件事：增加一條學(xué)生記錄、修改一條學(xué)生記錄、刪除一條學(xué)生記錄。如果要畫出用例圖，則以下兩種方法哪種更合適？方法1：用例如圖所示，分成3個腳本，分別畫3個交互圖。腳本1為增加學(xué)生記錄，腳本2為修改學(xué)生記錄，腳本3為刪除學(xué)生記錄。方法2：用例如圖所示，以后每個用例畫一個交互圖。注：交互圖包括順序圖和協(xié)作圖答: 從捕獲用戶需求的角度考慮,(教材)建議采用方法1. 采用方法2的一個主要問題是限制了分析人員的思路,雖然從用例圖可以發(fā)現(xiàn)，對學(xué)生記錄的操作有增加、修改和刪除，但事實上，用戶的真正目的可能不是對記錄進(jìn)行增加、修改或刪除,而是別的目的.如學(xué)生轉(zhuǎn)學(xué)這個要求,雖然這個要求會涉及學(xué)生記錄的增加、修改和刪除,但如果采用了方法2有可能會忽視了學(xué)生轉(zhuǎn)學(xué)這個真正的用戶需求. 采用了方法2的分析人員往往還是從數(shù)據(jù)處理的角度考慮,而不是從捕獲用戶需求的角度考慮