第3章3.2用例驅(qū)動的需求分析_第1頁
第3章3.2用例驅(qū)動的需求分析_第2頁
第3章3.2用例驅(qū)動的需求分析_第3頁
第3章3.2用例驅(qū)動的需求分析_第4頁
第3章3.2用例驅(qū)動的需求分析_第5頁
已閱讀5頁,還剩60頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

用例驅(qū)動的需求分析,什么是用例(UseCase)?,用例(UseCase):表示系統(tǒng)所提供的服務或可執(zhí)行的某種行為定義了系統(tǒng)是如何被參與者所使用的,描述了參與者為了使用系統(tǒng)所提供的某一完整功能而與系統(tǒng)之間發(fā)生的一段“對話”。用例的概念在1986年由IvarJacobson正式提出之后被廣泛接受,迅速發(fā)展,已成為OO、UML、RUP的標準規(guī)范和方法。描述需求的時候:系統(tǒng)有誰在用?這些人通過系統(tǒng)來做什么?,用例圖的要素,用例方法的基本思想:從用戶的角度來看,他們并不想了解系統(tǒng)的內(nèi)部結(jié)構(gòu)和設(shè)計,他們所關(guān)心的是系統(tǒng)所能提供的服務,也就是被開發(fā)出來的系統(tǒng)將是如何被使用的。用例模型主要由以下模型元素構(gòu)成:參與者(Actor):存在于被定義系統(tǒng)外部并與該系統(tǒng)發(fā)生交互的人或其他系統(tǒng),代表系統(tǒng)的使用者或使用環(huán)境。用例(UseCase)通訊關(guān)聯(lián)(CommunicationAssociation):用于表示參與者和用例之間的對應關(guān)系,它表示參與者使用了系統(tǒng)中的哪些服務(用例)、系統(tǒng)所提供的服務(用例)是被哪些參與者所使用的。,參與者,用例,通訊關(guān)聯(lián),一種新的需求分析技術(shù):用例,用例方法的優(yōu)點,系統(tǒng)被看作是一個黑箱,并不關(guān)心系統(tǒng)內(nèi)部是如何完成它所提供的功能的。首先描述了被定義系統(tǒng)有哪些外部使用者(抽象為Actor)、這些使用者與被定義系統(tǒng)發(fā)生交互;針對每一執(zhí)行者,又描述了系統(tǒng)為這些執(zhí)行者提供了什么樣的服務(抽象成為UseCase)、或者說系統(tǒng)是如何被這些執(zhí)行者使用的;,用例建模的基本過程,Step1:確定系統(tǒng)邊界Step2:識別并描述參與者(actor);Step3:識別用例(usecase),并給出簡要描述;Step4:識別執(zhí)行者與用例之間的關(guān)聯(lián)(Association);Step5:給出每一個用例的詳細描述Step6:細化用例模型,Step1:確定系統(tǒng)邊界,系統(tǒng)目標系統(tǒng)范圍,例:學生成績管理系統(tǒng)目標:大學?中小學?范圍:單機、網(wǎng)絡?學籍?課程?,Step2:識別并描述參與者(actor),參與者(actor)是指在系統(tǒng)外部與系統(tǒng)交互的人或其他系統(tǒng),他以某種方式參與了系統(tǒng)內(nèi)用例的執(zhí)行。,參與者的類型,參與者一般分為三種:人:與系統(tǒng)存在交互關(guān)系的使用者,管理員,用戶等設(shè)備:與系統(tǒng)存在交互關(guān)系的外部設(shè)備,條碼掃描儀,ic讀卡器,監(jiān)控攝像頭等其他系統(tǒng):與系統(tǒng)存在交互關(guān)系的其他系統(tǒng),成績管理系統(tǒng)的選課數(shù)據(jù)由選課系統(tǒng)提供。時間:有些用例需要系統(tǒng)時鐘定時觸發(fā),如員工生日祝福操作由系統(tǒng)時鐘檢測到生日時間后出發(fā),識別參與者,通過以下問題來識別Actor:誰使用這個系統(tǒng)的功能?誰從該系統(tǒng)獲得信息?誰向該系統(tǒng)提供信息?該系統(tǒng)需要訪問(讀寫)那些外部硬件設(shè)備?誰來負責維護和管理這個系統(tǒng)以保證其正常運行?該系統(tǒng)需要與其他系統(tǒng)進行交互嗎?,系統(tǒng)的主要功能使用者,系統(tǒng)的硬件設(shè)備,系統(tǒng)的維護、管理人員,其他系統(tǒng),例1:對一個圖書管理系統(tǒng)來說,有哪些參與者?讀者圖書管理者,例2:對ATM系統(tǒng)來說,有哪些參與者?銀行客戶ATM維護人員后臺服務器,銀行客戶,維護人員,后臺服務器,參與者的特點,在建模參與者過程中,記住以下要點。(1)參與者對于系統(tǒng)而言總是外部的,因此它們在你的控制之外。(2)參與者直接同系統(tǒng)交互,這可以幫助定義系統(tǒng)邊界。(3)參與者表示人和事物與系統(tǒng)發(fā)生交互時所扮演的角色,而不是特定的人或特定的事物。(4)一個人或事物在與系統(tǒng)發(fā)生交互時,可以同時或不同時扮演多個角色。例如,某研究生擔任某教授的助教,同職業(yè)的角度看,他扮演了兩個角色學生和助教。(5)每一個參與者需要有一個具有業(yè)務一樣的名字,在建模中,不推薦使用諸如NewActor這樣的名字。(6)每個參與者必須有簡短的描述,從業(yè)務角度描述參與者是什么。(7)像類一樣,參與者可以具有分欄,表示參與者屬性和它可接受的事件。一般情況下,這種分欄使用的并不多,很少顯示在用例圖中。,分組討論:找出參與者,按照分組選擇題目進行討論時間:5分鐘1、圖書管理系統(tǒng)的參與者(1-4組)2、學生餐飲管理系統(tǒng)的參與者(5-8組),Step3:識別用例(usecase),找到參與者之后,據(jù)此來確定系統(tǒng)的用例,主要是看各參與者需要系統(tǒng)提供什么樣的服務,或者說執(zhí)行者是如何使用系統(tǒng)的。尋找用例可以從以下問題入手(針對每一個參與者):參與者使用該系統(tǒng)執(zhí)行什么任務?參與者是否會在系統(tǒng)中創(chuàng)建、修改、刪除、訪問、存儲數(shù)據(jù)?如果是的話,執(zhí)行者又是如何來完成這些操作的?參與者是否會將外部的某些事件通知給該系統(tǒng)?系統(tǒng)是否會將內(nèi)部的某些事件通知該執(zhí)行者?,用例的特征,這件事必須由一個執(zhí)行者發(fā)起,執(zhí)行者的愿望是用例存在的原因。不存在沒有執(zhí)行者的用例,也不應該主動啟動另一個用例。,用例是相對獨立的,即用例的“功能”是完備的,用例的執(zhí)行結(jié)果對執(zhí)行者來說是可觀測和有意義的,用例必然是以動賓短語形式出現(xiàn)的。,識別用例,例1:對圖書館管理系統(tǒng)來說,有哪些參與者和用例?,圖書管理員管理讀者信息管理圖書信息登記借書登記還書,例2:對ATM系統(tǒng)來說,有哪些參與者和用例?,銀行客戶查詢?nèi)】钷D(zhuǎn)賬,普通讀者:預訂圖書取消預訂查詢?yōu)g覽圖書信息,ATM維護人員維護系統(tǒng)后臺服務器周期性操作,Step4:識別執(zhí)行者與用例之間的關(guān)聯(lián),數(shù)據(jù)流向由誰啟動,Step3:識別執(zhí)行者與用例之間的關(guān)聯(lián),數(shù)據(jù)流向由誰啟動,Step3:識別執(zhí)行者與用例之間的關(guān)聯(lián),數(shù)據(jù)流向由誰啟動,參與者與用例的關(guān)系,啟動用例,獲取用例的服務為用例提供服務,給系統(tǒng)提供信息,討論,討論下面的用例圖,有什么問題?,目標和步驟的誤區(qū),用戶觀點而非系統(tǒng)觀點,用戶觀點,系統(tǒng)觀點,用例的粒度,ATM取錢的場景中,取錢,讀卡,驗證賬號,打印回執(zhí)單等都是可能的用例?用例粒度的劃分最標準的方法應該是:以該用例是否完成了執(zhí)行者的某個完整目的為依據(jù)的。,案例:ATM的用例,客戶代表說:我希望這臺ATM能支持跨行業(yè)務,我插入卡片并輸入密碼后,可以讓我選擇是取錢還是存錢;為了方便,可以設(shè)置一些默認的存取金額按鈕;我可以修改密碼,也可以掛失;還有我希望可以交納水費、電費和電話等費用;為了安全起見,ATM上應當有警示小心騙子的提示條,還有攝像頭;如果輸入三次密碼錯誤,卡片應當被自動吞沒。,判斷下列操作,哪些是用例,支持跨行業(yè)務插入卡片輸入密碼選擇服務取錢存錢修改密碼掛失卡片交納費用警示騙子三次錯誤吞沒卡片,支持跨行業(yè)務錯,這是一個業(yè)務規(guī)則,限定業(yè)務的范圍插入卡片錯,這是一個過程步驟,不是完整目標輸入密碼錯,這是一個過程步驟,不是完整目標選擇服務錯,這是一個過程步驟,不是完整目標取錢對,這是一個完整有效的目標存錢對,這是一個完整有效的目標修改密碼對,這是一個完整有效的目標掛失卡片對,這是一個完整有效的目標交納費用對,這是一個完整有效的目標警示騙子錯,已超出了邊界范圍三次錯誤吞沒卡片錯,這是一個業(yè)務規(guī)則,限定業(yè)務的范圍,ATM的用例,“四輪馬車”C(Create)R(Read)U(Update)D(Delete)所有業(yè)務最終對會成為CRUD?CRUD能為Actor提供價值?CRUD掩蓋業(yè)務,銳變成關(guān)系數(shù)據(jù)庫的建模:“系統(tǒng)就是數(shù)據(jù)的增刪改查”關(guān)心數(shù)據(jù)的存儲和維護,反而忽略了用戶的目的,用例的粒度2,如果確實是CRUD?如果CRUD不涉及復雜的交互,一個用例“管理”即可不管是C、R、U、D,都是為了完成“管理”目標甚至很多種的基本數(shù)據(jù)管理都可以用一個用例表示,討論,電子郵件系統(tǒng),有如下功能:發(fā)件人A發(fā)送郵件給B,系統(tǒng)提醒B你有“新郵件”,收件人B接收郵件。畫出用例圖,Step5:給出用例的詳細描述,單純的用例圖并不能描述完整的信息,需要用文字描述不能反映在圖形上的信息。,用例名稱用例標識涉及的參與者描述用例的規(guī)格說明前置條件PreConditions后置條件PostConditions正常事件流Flowofevents備選事件流Alternateflow其它非功能需求、設(shè)計約束、尚存在的問題,前置、后置條件,前置條件約束在用例開始前系統(tǒng)的狀態(tài)把它們看做是看門人,它阻止參與者觸發(fā)該用例直到滿足所有條件說明在用例觸發(fā)之前什么必須為真后置條件約束用例執(zhí)行后系統(tǒng)的狀態(tài)用例執(zhí)行后什么必須為真對于有多個事件流的用例,則應該有多個后置條件某些用例依賴于其他用例一個用例在離開系統(tǒng)時,可能是另一個用例的前置條件(例如:“登錄”和“管理系統(tǒng)”)有助于識別漏掉的用例如果一個用例的前置條件不能有執(zhí)行其他用例滿足,可能意味著丟失了用例(例如:“管理訂單”卻沒有“登錄”用例),事件流,用例的事件流:說明用例如何啟動,即哪些執(zhí)行者在何種情況下啟動用例?說明執(zhí)行者與用例之間的信息處理過程;說明用例在不同條件下可以選擇執(zhí)行的多種方案;說明用例在什么情況下才能被視作完成;分為常規(guī)流和備選流兩類:常規(guī)流:描述該用例最正常的一種場景,系統(tǒng)執(zhí)行一系列活動步驟來響應執(zhí)行者提出的服務請求;備選流:負責描述用例執(zhí)行過程中異常的或偶爾發(fā)生的一些情況。,常規(guī)事件流,每一個步驟都需要用數(shù)字編號以清楚地標明步驟的先后順序。用一句簡短的標題來概括每一步驟的主要內(nèi)容。對每一步驟,從兩個方面來描述:執(zhí)行者向系統(tǒng)提交了什么信息;對此系統(tǒng)有什么樣的響應。,備選事件流,備選流的描述格式可以與基本流的格式一致,也需要編號并以標題概述其內(nèi)容。起點:該備選流從事件流的哪一步開始;條件:在什么條件下會觸發(fā)該備選流;動作:系統(tǒng)在該備選流下會采取哪些動作;恢復:該備選流結(jié)束之后,該用例應如何繼續(xù)執(zhí)行。,事件流描述要點,1.只書寫“可觀測”的(說人話)2.使用主動語句3.句子必須以參與者或系統(tǒng)作為主語4.不要涉及界面細節(jié)5.分支和循環(huán),只寫“可觀測”的,系統(tǒng)通過ADO建立數(shù)據(jù)庫連接,傳送SQL查詢語句,從“商品表”查詢商品的詳細信息系統(tǒng)按照查詢條件搜索商品的詳細信息,主動語句,歐文叢貝克漢姆處得到傳球,守門員貝克漢姆傳球給歐文,歐文射門,守門員撲救出納員系統(tǒng),以參與者或系統(tǒng)作主語,參與者系統(tǒng)出納員接收顧客的付款顧客的付款數(shù)可能高于商品總額出納員錄入顧客所付的現(xiàn)金總額系統(tǒng)顯示出應找還給顧客的余額,打印付款收據(jù),不涉及界面細節(jié),會員從下拉框中選擇類別會員在相應文本框中輸入查詢條件會員點擊“確定”按鈕,分支和循環(huán),分支:放到擴展路徑(備選事件流)參與者的選擇另一條成功線路系統(tǒng)進行驗證循環(huán):直接描述,處理銷售,1.顧客攜帶所購商品或服務到收銀臺通過POS機付款。2.收銀員開始一次新的銷售交易。3.收銀員輸入商品條碼。4.系統(tǒng)逐條記錄出售的商品,并顯示該商品的描述、價格和累計金額。價格通過一組價格規(guī)則來計算。5.收銀員重復3-4步,直到輸入結(jié)束。6.收銀員告知顧客總額,并請顧客付款。7.顧客付款,系統(tǒng)顯示找零信息,并處理支付。8.系統(tǒng)記錄完整的銷售信息,并將銷售和支付信息發(fā)送到外部的賬務系統(tǒng)(進行賬務處理和提成)和庫存系統(tǒng)(更新庫存)。9.系統(tǒng)打印票據(jù)。10.顧客攜帶商品和票據(jù)離開。,處理銷售的用例描述,用例名稱:處理銷售參與者與關(guān)注點:收銀員:希望準確、快速地輸入,而且沒有支付錯誤,因為如果少收貨款,將從其工資中扣除。前置條件:收銀員必須經(jīng)過確認和認證后置條件:存儲銷售信息。準確計算稅金。更新賬務和庫存信息。基本流程:1.顧客攜帶所購商品或服務到收銀臺通過POS機付款。2.收銀員開始一次新的銷售交易。3.收銀員輸入商品條碼擴展流程:3a.無效商品ID(在系統(tǒng)中未發(fā)現(xiàn)):系統(tǒng)提示錯誤并拒絕輸入該ID。收銀員響應該錯誤特殊需求:使用大尺寸平面顯示器觸摸屏,文本信息可見距離為1米發(fā)生頻率:可能會不斷地發(fā)生未解決問題:提成處理規(guī)則不確定收銀員換班時如何處理,Step6:細化用例模型,執(zhí)行者與執(zhí)行者之間的泛化(generalization)用例和用例之間的包含(include)用例和用例之間的擴展(extend)用例和用例之間的泛化(generalization)關(guān)系利用這些關(guān)系來調(diào)整已有的用例模型,把一些公共的信息抽取出來復用,使得用例模型更易于維護。,泛化(Generalization)關(guān)系,執(zhí)行者之間的泛化,泛化(Generalization),用例之間的泛化,用例間的泛化關(guān)系表明子用例包含父用例中定義的所有屬性、行為序列和擴展點,并且參與父用例中所有的關(guān)系,包含(Include),箭頭指向的用例為被包含的用例,稱為包含用例;箭頭出發(fā)的用例為基本用例。包含用例是必選的,如果缺少包含用例,基礎(chǔ)用例就不完整;包含用例必須被執(zhí)行,不需要滿足某種條件;其執(zhí)行并不會改變基用例的行為。,包含(Include),某些步驟在多個用例重復出現(xiàn),且單獨形成價值用例步驟較多時,可用Include簡化,擴展(Extend),將擴展用例的事件流在一定的條件下按照相應的擴展點插入到基礎(chǔ)用例中?;A(chǔ)用例不必知道擴展用例的任何細節(jié),它僅為其提供擴展點。擴展用例的行為是否被執(zhí)行要取決于主事件流中的判定點。,箭頭指向的用例為被擴展的用例,稱為擴展用例;箭頭出發(fā)的用例為基本用例。擴展

溫馨提示

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

評論

0/150

提交評論