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