第3章用例和用例圖-3_第1頁(yè)
第3章用例和用例圖-3_第2頁(yè)
第3章用例和用例圖-3_第3頁(yè)
第3章用例和用例圖-3_第4頁(yè)
第3章用例和用例圖-3_第5頁(yè)
已閱讀5頁(yè),還剩68頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、周一周四周六第十一周智慧城市5月5日敏捷開(kāi)發(fā);社交網(wǎng)絡(luò)5月8日XP(極限編程);Scrum敏捷開(kāi)發(fā)5月10日第十二周IT運(yùn)維/運(yùn)維即服務(wù);DevOps5月12日面向方面的程序設(shè)計(jì);面向服務(wù)架構(gòu)/Web服務(wù)5月15日第十三周工作流;云計(jì)算5月19日大數(shù)據(jù);自主計(jì)算5月22日物聯(lián)網(wǎng)/車(chē)聯(lián)網(wǎng);Hadoop5月24日第十四周數(shù)據(jù)挖掘;業(yè)務(wù)流程管理5月26日虛擬化技術(shù);Google產(chǎn)品5月29日用例之間的關(guān)系包括: 泛化關(guān)系(generalization) 包含關(guān)系(include) 擴(kuò)展關(guān)系(extend)當(dāng)發(fā)現(xiàn)系統(tǒng)中有兩個(gè)或者多個(gè)用例在行為、結(jié)構(gòu)、目的方面存在共性時(shí)就可以使用泛化關(guān)系。可以用新的用例

2、來(lái)描述共有部分,這個(gè)新用例就是父用例。 一次性付款分期付款貨到付款客戶支付費(fèi)用1.多個(gè)用例用到同一部分的行為,則可以把這部分行為單獨(dú)抽象為一個(gè)用例,然后讓其他用例來(lái)包含這一用例。LoginAdd to Wish ListCustomerCheckout2.某個(gè)用例的功能過(guò)多、事件流過(guò)于復(fù)雜時(shí)也可以把某一段事件流抽象為一個(gè)被包含的用例,以達(dá)到簡(jiǎn)化描述的目的。l 在一定條件下,把新的行為加入到已有的用例中,獲得的新用例叫擴(kuò)展用例,原有的用例叫基本用例。交納罰金還車(chē)租車(chē)用戶u泛化關(guān)系中所有子用例都有相似的目的和結(jié)構(gòu),它們是整體上的相似。u包含關(guān)系中,基本用例在目的上可以完全不相同,但它們都有一段相似

3、的行為。它們的相似是部分的相似不是整體的相似。u泛化關(guān)系中,子用例和子用例之間是相互獨(dú)立的,任何一個(gè)子用例執(zhí)行不受其他子用例的影響。u包含關(guān)系中,基本用例的執(zhí)行必然引起被包含用例的執(zhí)行。u 基本用例的執(zhí)行并不一定會(huì)涉及擴(kuò)展用例,擴(kuò)展用例只是在滿足一定條件下才會(huì)被執(zhí)行。在包含關(guān)系中,當(dāng)基本用例被執(zhí)行時(shí),被包含用例一定會(huì)被執(zhí)行。u 即使沒(méi)有擴(kuò)展用例,擴(kuò)展關(guān)系中的基本用例本身就是完整的。包含關(guān)系中,基本用例在沒(méi)有被包含用例的情況下可能是不完整存在的。商店銷(xiāo)售系統(tǒng)中,售貨員可以使用系統(tǒng)處理客戶訂單和處理返回的次品。兩個(gè)進(jìn)程都需要驗(yàn)證客戶。畫(huà)出用例圖。Check customer validityTak

4、e customer orderSales assistantReturn faulty goods在線機(jī)票預(yù)定系統(tǒng):當(dāng)客戶訂機(jī)票時(shí)可以選擇升級(jí)他們的座位(比如從經(jīng)濟(jì)艙到商務(wù)艙)Upgrade seatCustomerBook flight圖書(shū)管理系統(tǒng)中,借閱人可以借閱圖書(shū)、歸還圖書(shū)、查詢圖書(shū)。當(dāng)超期歸還圖書(shū)時(shí),借閱人需要繳納罰款。畫(huà)出用例圖。借閱圖書(shū)歸還圖書(shū)借閱人查詢圖書(shū)繳納罰款在線買(mǎi)賣(mài)系統(tǒng)里,買(mǎi)家和賣(mài)家需要注冊(cè)他們的銀行賬戶信息。如果這個(gè)銀行賬戶不是可用的或合法的,系統(tǒng)將啟動(dòng)一個(gè)單獨(dú)的進(jìn)程進(jìn)行處理。Process unacceptable accountBuyerSellerRegiste

5、r bank accountJH: 當(dāng)我們保險(xiǎn)公司員工賣(mài)保險(xiǎn)時(shí),第一件事情就是獲得會(huì)員客戶的信息:年齡、職業(yè)、住址、保險(xiǎn)歷史-近期是否發(fā)生過(guò)車(chē)禍MP: 這些信息從哪里獲得?JH: 一部分從系統(tǒng)里他們的會(huì)員信息獲得,另一部分通過(guò)電話聯(lián)系他們獲得MP: 然后呢?JH: 我們將基于我們獲得的信息搜索到合適的保險(xiǎn)產(chǎn)品。系統(tǒng)可能會(huì)返回多個(gè)保險(xiǎn)產(chǎn)品,我們將推薦給客戶最能滿足客戶需要的產(chǎn)品。MP: 每次都會(huì)順利成交嗎?JH: 不,有些客戶會(huì)決定購(gòu)買(mǎi),有些不會(huì)。MP: 所以你推薦保險(xiǎn)產(chǎn)品時(shí)都先搜索產(chǎn)品,但只有某些時(shí)候會(huì)成交也就是賣(mài)掉產(chǎn)品。JH: 對(duì)請(qǐng)畫(huà)出用例圖。Sell PolicySearch for Po

6、licyInsurance AdministratorRecommend PolicySell PolicySearch for PolicyInsurance AdministratorRecommend Policy自動(dòng)售貨機(jī)能提供6種不同的飲料,售貨機(jī)上有6個(gè)不同的按鈕,分別對(duì)應(yīng)這6種不同的飲料,顧客通過(guò)這些按鈕選擇不同的飲料。售貨機(jī)有一個(gè)硬幣槽和找零槽,分別用來(lái)收錢(qián)和找錢(qián)。畫(huà)出這個(gè)自動(dòng)售貨機(jī)系統(tǒng)的用例圖出零錢(qián)出飲料投幣按按鈕選擇飲料顧客買(mǎi)飲料供貨供貨人取貨款“遠(yuǎn)程網(wǎng)絡(luò)教學(xué)系統(tǒng)”的功能需求如下:學(xué)生登錄網(wǎng)站后,可以瀏覽課件、查找課件、下載課件、觀看教學(xué)視頻。教師登錄網(wǎng)站后,可以上傳課件、

7、上傳教學(xué)視頻、發(fā)布教學(xué)心得、查看教學(xué)心得、 修改教學(xué)心得。學(xué)生和教師都需要登錄“遠(yuǎn)程網(wǎng)絡(luò)教學(xué)系統(tǒng)”后才能正常使用該系統(tǒng)的所有功能。如果忘記密碼,可與通過(guò)“找回密碼”功能找回密碼。請(qǐng)畫(huà)出用例圖。 UML初學(xué)者 缺少用例的描述或用例的描述不完整 用例是一個(gè)“文字描述序列” 用例是“動(dòng)作序列的說(shuō)明” 用例的描述才是用例的主要部分 是后續(xù)的交互圖分析和類(lèi)圖分析必不可少的部分。 用例的描述應(yīng)該包含哪些內(nèi)容,并沒(méi)有一個(gè)統(tǒng)一的標(biāo)準(zhǔn),不同的開(kāi)發(fā)機(jī)構(gòu)可能會(huì)有不同的要求,但一般應(yīng)包括以下內(nèi)容: 用例的目標(biāo) 用例是怎么啟動(dòng)的 參與者和用例之間的消息是如何傳送的 用例中除了主路徑外,其他路徑是什么 用例結(jié)束后的系統(tǒng)狀

8、態(tài) 其他需要描述的內(nèi)容 描述用例的原則是盡可能寫(xiě)得“充分”,而不是追求寫(xiě)得形式化、完整或漂亮。 作為OOA文檔的一個(gè)組成部分,用例的描述應(yīng)該有一定的規(guī)范格式,但目前并沒(méi)有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。在統(tǒng)一的標(biāo)準(zhǔn)出現(xiàn)之前,人們可以采納適合于自己的用例描述格式,但不管怎樣,在一個(gè)開(kāi)發(fā)機(jī)構(gòu)內(nèi)部應(yīng)該采用統(tǒng)一的格式。 描述項(xiàng)描述項(xiàng)說(shuō)明說(shuō)明用例名稱表明用戶的意圖或用例的用途,如“劃撥資金”標(biāo)識(shí)符可選唯一標(biāo)識(shí)符,如“UC1701”,在文檔的別處可以用標(biāo)識(shí)符來(lái)引用這個(gè)用例用例描述概述用例的幾句話參與者與此用例相關(guān)的參與者列表優(yōu)先級(jí)一個(gè)有序的排列,1代表優(yōu)先級(jí)最高狀態(tài)可選用例的狀態(tài),通常為以下幾種之一:進(jìn)行中、等待審查、通

9、過(guò)審查或未通過(guò)審查前置條件一個(gè)條件列表,如果其中包含條件,則這些條件必須在訪問(wèn)用例之前得到滿足后置條件一個(gè)條件列表,如果其中包含條件,則這些條件將在用例完成以后得到滿足基本操作流程描述用例中各項(xiàng)工作都正常進(jìn)行時(shí)用例的工作方式可選操作流程描述變更工作方式、出現(xiàn)異?;虬l(fā)生錯(cuò)誤的情況下所遵循的路徑被泛化的用例此用例所泛化的用例列表被包含的用例此用例所包含的用例列表被擴(kuò)展的用例此用例所擴(kuò)展的用例列表修改歷史記錄可選關(guān)于用例的修改時(shí)間、修改原因和修改人的詳細(xì)信息問(wèn)題可選與此用例的開(kāi)發(fā)相關(guān)的問(wèn)題列表決策可選關(guān)鍵決策的列表,將這些決策記錄下來(lái)以便維護(hù)時(shí)使用頻率可選參與者訪問(wèn)此用例的頻率,如用戶是每日訪問(wèn)一次

10、還是每月訪問(wèn)一次 表3.3 是對(duì)“處理訂單”這個(gè)用例的描述。 具體內(nèi)容見(jiàn)書(shū)P31. UML初學(xué)者易犯的錯(cuò)誤只描述系統(tǒng)的行為,沒(méi)有描述參與者的行為只描述參與者的行為,沒(méi)有描述系統(tǒng)的行為在用例描述中就設(shè)定對(duì)用戶界面的設(shè)計(jì)的要求描述過(guò)于冗長(zhǎng) Cockburn在Coc00中給出了很多錯(cuò)誤的用例描述的例子。下面給出幾個(gè)典型的例子。(為了說(shuō)明問(wèn)題,在給出描述時(shí)并沒(méi)有完全按照表3.2中用例描述模板的格式,只給出了操作流程的描述。) 【例3.5】下面是一個(gè)用例描述的片斷:Use Case:Withdraw Cash參與者:Customer主事件流: 儲(chǔ)戶插入ATM卡,并鍵入密碼。 儲(chǔ)戶按Withdraw按鈕,

11、并鍵入取款數(shù)目。 儲(chǔ)戶取走現(xiàn)金,ATM卡并拿走收據(jù)。 儲(chǔ)戶離開(kāi)。【例3.6】下面是一個(gè)用例描述的片斷:Use Case:Withdraw Cash參與者:Customer主事件流:(1) ATM系統(tǒng)獲得ATM卡和密碼。(2) 設(shè)置事務(wù)類(lèi)型為Withdrawal。(3) ATM系統(tǒng)獲取要提取的現(xiàn)金數(shù)目。(4) 驗(yàn)證賬戶上是否有足夠儲(chǔ)蓄金額。(5) 輸出現(xiàn)金、數(shù)據(jù)和ATM卡。(6) 系統(tǒng)復(fù)位。 主事件流:(1) 通過(guò)讀卡機(jī),儲(chǔ)戶插入ATM卡。(2) ATM系統(tǒng)從卡上讀取銀行ID、賬號(hào)、加密密碼、并用主銀行密碼驗(yàn)證銀行ID和賬號(hào)。(3) 儲(chǔ)戶鍵入密碼,ATM系統(tǒng)根據(jù)上面讀出的卡上加密密碼,對(duì)密碼進(jìn)行

12、驗(yàn)證。(4) 儲(chǔ)戶按FASTCASH按鈕,并鍵入取款數(shù)量,取款數(shù)量應(yīng)該是5美元的倍數(shù)。(5) ATM系統(tǒng)通知主銀行系統(tǒng),傳遞儲(chǔ)戶賬號(hào)和取款數(shù)量,并接收返回的確認(rèn)信息和儲(chǔ)戶賬戶余額。(6) ATM系統(tǒng)輸出現(xiàn)金、ATM卡和顯示賬戶余額的收據(jù)。(7) ATM系統(tǒng)記錄事務(wù)到日志文件?!纠?.7】下面是一個(gè)用例描述的片斷:Use Case:Buy Something參與者:Customer主事件流:(1) 系統(tǒng)顯示ID and Password窗口。(2) 顧客鍵入ID和密碼,然后按OK按鈕。(3) 系統(tǒng)驗(yàn)證顧客ID和密碼,并顯示Personal Information窗口。(4) 顧客鍵入姓名、街道地

13、址、城市、郵政編碼、電話號(hào)碼,然后按OK按鈕。(5) 系統(tǒng)驗(yàn)證用戶是否為老顧客。(6) 系統(tǒng)顯示可以賣(mài)的商品列表。(7) 顧客在準(zhǔn)備購(gòu)買(mǎi)的商品圖片上單擊,并在圖片旁邊輸入要購(gòu)買(mǎi)的數(shù)量。選購(gòu)商品完畢后按Done按鈕。(8) 系統(tǒng)通知庫(kù)存系統(tǒng)驗(yàn)證要購(gòu)買(mǎi)的商品是否有足夠的庫(kù)存。(后續(xù)描述省略) 上述描述中存在的問(wèn)題是對(duì)用戶界面的描述過(guò)于詳細(xì)。對(duì)于需求文檔來(lái)說(shuō),詳細(xì)地用戶界面描述對(duì)捕獲需求并無(wú)幫助。改進(jìn)的描述如下所示:Use Case:Buy Something參與者:Customer主事件流: (1) 顧客使用ID和密碼進(jìn)入系統(tǒng)。(2) 系統(tǒng)驗(yàn)證顧客身份。(3) 顧客提供姓名、地址、電話號(hào)碼。(4)

14、 系統(tǒng)驗(yàn)證顧客是否為老顧客。(5) 顧客選擇要購(gòu)買(mǎi)的商品和數(shù)量。(6) 系統(tǒng)通過(guò)庫(kù)存系統(tǒng)驗(yàn)證要購(gòu)買(mǎi)的商品是否具有足夠庫(kù)存。(后續(xù)描述省略) 【例3.8】下面是一個(gè)用例描述的片斷:Use Case:Buy Something參與者:Customer主事件流:(1) 顧客使用ID和密碼進(jìn)入系統(tǒng)。(2) 系統(tǒng)驗(yàn)證顧客身份。(3) 顧客提供姓名。(4) 顧客提供地址。 (5) 顧客提供電話號(hào)碼。(6) 顧客選取商品。(7) 顧客確定商品的數(shù)量。(8) 系統(tǒng)驗(yàn)證顧客是否為老顧客。(9) 系統(tǒng)打開(kāi)到庫(kù)存系統(tǒng)的連接。(10) 系統(tǒng)通過(guò)庫(kù)存系統(tǒng)請(qǐng)求當(dāng)前庫(kù)存量。(11) 庫(kù)存系統(tǒng)返回當(dāng)前庫(kù)存量。(12) 系統(tǒng)驗(yàn)

15、證購(gòu)買(mǎi)商品的數(shù)量是否少于庫(kù)存量。(后續(xù)描述省略) 上述描述中存在的問(wèn)題是對(duì)于用例的描述過(guò)于冗長(zhǎng)。可以采用更為簡(jiǎn)潔的描述方式。如合并類(lèi)似的數(shù)據(jù)項(xiàng)(步驟(3)至步驟(5),提供抽象的高層描述(步驟(9)至步驟(12)等。改進(jìn)的描述可以如下所示:Use Case:Buy Something參與者:Customer主事件流: (1) 顧客使用ID和密碼進(jìn)入系統(tǒng)。(2) 系統(tǒng)驗(yàn)證顧客身份。(3) 顧客提供個(gè)人信息(包括姓名、地址、電話號(hào)碼),選擇要購(gòu)買(mǎi)的商品及數(shù)量。(4) 系統(tǒng)驗(yàn)證顧客是否為老顧客。(5) 系統(tǒng)使用庫(kù)存系統(tǒng)驗(yàn)證要購(gòu)買(mǎi)的商品數(shù)量是否少于庫(kù)存量。(后續(xù)描述省略)主事件流:輸入密碼,登錄成功異

16、常事件流輸入密碼后清除密碼,重新輸入密碼,登錄成異常事件流輸入密碼錯(cuò)誤三次,銀行卡被ATM吞掉描述ATM系統(tǒng)中驗(yàn)證用戶用例:用例名、用例描述、前置條件、基本操作流程、基本操作流程的后置條件、可選操作流程、可選操作流程的后置條件用戶驗(yàn)證用戶用例名驗(yàn)證用戶用例描述當(dāng)一個(gè)用戶插卡后是這個(gè)用例的開(kāi)始。它處理有關(guān)用戶驗(yàn)證的問(wèn)題。前置條件用戶插入銀行卡基本操作流程用戶提交密碼信息系統(tǒng)檢查密碼是否正確。如果有效系統(tǒng)進(jìn)入歡迎頁(yè)面基本操作流程的后置條件用戶被準(zhǔn)許轉(zhuǎn)賬等其他操作用例名驗(yàn)證用戶可選操作流程1用戶在提交密碼之前清除密碼用戶重新輸入密碼并提交密碼系統(tǒng)檢查密碼是否正確。如果有效系統(tǒng)進(jìn)入歡迎頁(yè)面可選操作流程

17、1的后置條件用戶被準(zhǔn)許轉(zhuǎn)賬等其他操作可選操作流程2如果用戶輸入錯(cuò)誤密碼,用例重啟如果發(fā)生輸入密碼錯(cuò)誤三次,取款卡被ATM吞掉可選操作流程2的后置條件用戶銀行卡被吞網(wǎng)上書(shū)店,用戶購(gòu)買(mǎi)圖書(shū)前需要登錄。對(duì)于每個(gè)登錄用例有兩個(gè)事件流:基本操作流程:登錄成功可選操作流程:登錄不成功描述登錄用例:用例名、用例描述、前置條件、基本操作流程、基本操作流程的后置條件、可選操作流程、可選操作流程的后置條件用戶登錄用例名登錄用例描述處理有關(guān)用戶登錄系統(tǒng)的問(wèn)題。用戶需要登錄后才能購(gòu)買(mǎi)書(shū)籍。前置條件一個(gè)注冊(cè)的用戶基本操作流程用戶提交用戶名和密碼系統(tǒng)驗(yàn)證登錄信息用戶是注冊(cè)用戶,系統(tǒng)顯示用戶個(gè)人主頁(yè)基本操作流程的后置條件用

18、戶被準(zhǔn)許購(gòu)書(shū)操作用例名驗(yàn)證用戶可選操作流程 用戶提交用戶名和密碼系統(tǒng)驗(yàn)證登錄信息用戶登錄信息不存在,系統(tǒng)顯示消息通知用戶可選操作流程的后置條件用戶不允許進(jìn)行購(gòu)書(shū)操作 用例分析的步驟可以按下面的順序進(jìn)行:(1) 找出系統(tǒng)外部的參與者和外部系統(tǒng),確定系統(tǒng)的邊界和范圍。(2) 確定每一個(gè)參與者所期望的系統(tǒng)行為。(3) 把這些系統(tǒng)行為命名為用例。(4) 使用泛化、包含、擴(kuò)展等關(guān)系處理系統(tǒng)行為的公共或變更部分。(5) 編制每一個(gè)用例的腳本。(6) 繪制用例圖。(7) 區(qū)分主事件流和異常情況的事件流,如果需要,可以把表示異常情況的事件流作為單獨(dú)的用例處理。(8) 細(xì)化用例圖,解決用例間的重復(fù)與沖突問(wèn)題。

19、當(dāng)然上述這個(gè)順序并不是固定的,可以根據(jù)需要進(jìn)行一些調(diào)整。 采用用例分析法捕獲用戶的需求,其中一個(gè)比較困難的工作是確定系統(tǒng)應(yīng)該包含哪些用例,以及如何有效地發(fā)現(xiàn)這些用例。事實(shí)上,在做用例分析時(shí),并沒(méi)有一個(gè)固定的方式或方法來(lái)發(fā)現(xiàn)用例,而且對(duì)于同一個(gè)系統(tǒng),往往會(huì)有很多種解決方案,但其中某些方案會(huì)比另一些方案好。 與設(shè)計(jì)和實(shí)現(xiàn)階段相比,需求分析階段更多的還是依賴于分析人員的個(gè)人經(jīng)驗(yàn)和領(lǐng)域知識(shí)。例如,如果某分析人員以前做過(guò)類(lèi)似的系統(tǒng)分析和開(kāi)發(fā)工作,那么以后再做類(lèi)似的工作時(shí)就比較容易,但如果是針對(duì)一個(gè)全新的領(lǐng)域,往往會(huì)覺(jué)得很難入手,這時(shí)就需要領(lǐng)域?qū)<业膸椭?下面的這些啟發(fā)性原則可以幫助分析人員發(fā)現(xiàn)用例:和

20、系統(tǒng)潛在用戶交流把自己當(dāng)作參與者,設(shè)想與系統(tǒng)進(jìn)行交互確定用例和確定參與者不能截然分開(kāi) Jacobson作為用例方法的提出者,也提出了一些原則來(lái)幫助發(fā)現(xiàn)用例,如通過(guò)回答下列問(wèn)題來(lái)幫助發(fā)現(xiàn)用例: 參與者的主要任務(wù)是什么? 參與者需要了解系統(tǒng)的什么信息?需要修改系統(tǒng)的什么信息? 參與者是否需要把系統(tǒng)外部的變化通知系統(tǒng)? 參與者是否希望系統(tǒng)把異常情況的變化通知自己?(1) 用例的粒度問(wèn)題。對(duì)于一個(gè)系統(tǒng)來(lái)說(shuō),不同的人進(jìn)行用例分析后得到的用例數(shù)目有多有少。如果用例粒度(granularity)很大,那么得到的用例數(shù)就會(huì)很少,如果用例粒度很小,那么得到的用例數(shù)就會(huì)很多。那么用例數(shù)目多少比較合適? 答:這是很

21、多人爭(zhēng)論的問(wèn)題。例如:Ivar Jacobson認(rèn)為,對(duì)于一個(gè)10人年的項(xiàng)目,他需要大約20個(gè)用例,而在一個(gè)相同規(guī)模的項(xiàng)目中,Martin Fowler則用了100多個(gè)用例。(Martin Fowler是流行的UML入門(mén)書(shū)“UML distilled”的作者之一FS99,該書(shū)在UML領(lǐng)域的影響很大。) u簡(jiǎn)單的系統(tǒng),復(fù)雜度較低,可適當(dāng)加大用例數(shù);復(fù)雜的系統(tǒng),一個(gè)用例可包含較多的需求信息量。保證整個(gè)模型易理解。(2) 在一個(gè)系統(tǒng)中,有幾個(gè)相似的功能,那么是將他們放在同一個(gè)用例中,還是分成幾個(gè)用例?假設(shè)有這樣的需求,在學(xué)生檔案管理中,管理員經(jīng)常需要做3件事:增加一條學(xué)生記錄、修改一條學(xué)生記錄、刪除

22、一條學(xué)生記錄。如果要畫(huà)出用例圖,則以下兩種方法哪種更合適? 方法方法1:用例圖如圖3.10所示,并分成3個(gè)腳本。腳本1為增加學(xué)生記錄,腳本2為修改學(xué)生記錄,腳本3為刪除學(xué)生記錄。管理員學(xué)生記錄管理方法方法2:用例圖如圖3.11所示。 (3) 三層結(jié)構(gòu)(數(shù)據(jù)庫(kù)層、邏輯層、表示層)如何采用用例表示?答:這也是一個(gè)非常典型的問(wèn)題。一般初學(xué)者在進(jìn)行用例分析時(shí),往往很容易會(huì)考慮到實(shí)現(xiàn)的問(wèn)題。事實(shí)上,用例是用來(lái)描述系統(tǒng)需求的,一般不在用例分析階段考慮系統(tǒng)的實(shí)現(xiàn)問(wèn)題。如果需要描述系統(tǒng)的三層結(jié)構(gòu),則在類(lèi)圖、部署圖等中表示。(4) 如圖3.12所示的用例圖和如圖3.13所示的用例圖有何區(qū)別,在表示用例的包含關(guān)系

23、方面是否正確? ABCD圖3.12 用例圖1圖3.13 用例圖2答:用例間的包含關(guān)系是依賴關(guān)系的版型,因此圖3.12是正確的表示方法。對(duì)于圖3.13,C和D之間存在泛化關(guān)系,而表示為泛化關(guān)系上的版型。當(dāng)然根據(jù)版型的定義,可以在泛化關(guān)系上加版型,但這只是在語(yǔ)法上成立,而在語(yǔ)義上,泛化關(guān)系上的版型并沒(méi)有特殊的用處。所以圖3.13這樣的表示方法是不恰當(dāng)?shù)摹?1用例是Ivar Jacobson發(fā)明的概念,用例驅(qū)動(dòng)的軟件開(kāi)發(fā)方法已得到廣泛的認(rèn)同。2用例是系統(tǒng)、子系統(tǒng)或類(lèi)與外部的參與者交互的動(dòng)作序列的說(shuō)明,包括可選的動(dòng)作序列和會(huì)出現(xiàn)的異常的動(dòng)作序列。3用例命名往往采用動(dòng)賓結(jié)構(gòu)或主謂結(jié)構(gòu)。4系統(tǒng)需求一般分為

24、功能性需求和非功能性需求兩部分,用例只涉及功能性方面的需求。5用例之間可以有泛化關(guān)系、包含關(guān)系、擴(kuò)展關(guān)系等。6腳本是用例的實(shí)例。7參與者是指系統(tǒng)以外的、需要使用系統(tǒng)或與系統(tǒng)交互的東西,包括人、設(shè)備、外部系統(tǒng)等。8參與者之間可以有泛化關(guān)系。 9用例的描述是用例的主要部分。10用例的描述格式?jīng)]有一個(gè)統(tǒng)一的標(biāo)準(zhǔn),不同的開(kāi)發(fā)機(jī)構(gòu)可以采用自認(rèn)為合適的格式。11用例分析結(jié)構(gòu)的好壞與分析人員的個(gè)人經(jīng)驗(yàn)和領(lǐng)域知識(shí)有很大的關(guān)系。 網(wǎng)上書(shū)店:注冊(cè)客戶可以使用系統(tǒng)下訂單,結(jié)帳,給書(shū)籍評(píng)分,和賣(mài)二手書(shū)籍給其他客戶。在進(jìn)行這些操作之前,客戶必須先使用用戶名和密碼來(lái)登錄系統(tǒng)。畫(huà)出網(wǎng)上書(shū)店系統(tǒng)的用例圖,考慮使用include和extend。寫(xiě)出每個(gè)用例的用例描述(用例描述、參與者、前置條件、基本事件流、可選事件流、后置條件)。提示:客戶下訂單、結(jié)帳、給書(shū)籍評(píng)分、賣(mài)二手書(shū)籍之前需要先登錄;客戶下訂單之后結(jié)帳。用例用例描述Register新客戶在使用系統(tǒng)進(jìn)行任何操作前需要首先注冊(cè)參與者: 客戶前置條件: 一個(gè)未注冊(cè)客戶主事件流:1. 客戶提交注冊(cè)所需的信息2. 系統(tǒng)檢查輸入的所有信息。更新數(shù)據(jù)庫(kù)中的客戶記錄。后置條件:新客戶已注冊(cè)。用例用例描述Log-in客戶在使用系統(tǒng)進(jìn)行任何操作時(shí)需要先登錄系統(tǒng)參與者:客戶前置條件:注冊(cè)客戶主事件流:1. 客戶提交用戶名和密碼2. 系

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論