1、2020/9/5,軟件工程方法,1,了解可行性研究與風險分析的方法 掌握可行性分析報告的書寫格式 掌握客戶需求分析的要點及需求分析規(guī)格說 明報告的書寫格式 掌握通過繪制用例圖及其正文描述來完成客 戶需求分析的方法 掌握UML的用例模型建模方法,本章目的：,第三章 需求分析與用例建模,2020/9/5,軟件工程方法,2,1.系統(tǒng)成本費用分析 設備購置費用。 系統(tǒng)開發(fā)費用。 系統(tǒng)安裝、運行和維護費用。 人員培訓費用。 2.系統(tǒng)效益分析 經(jīng)濟效益。 社會效益。,3.1.1 經(jīng)濟可行性研究,3.1 可行性研究與風險分析,2020/9/5,軟件工程方法,3,2020/9/5,軟件工程方法,4,1.風險分

2、析 2.資源分析 3. 技術分析 反映系統(tǒng)動態(tài)特性： 綜合系統(tǒng)的全部因素： 突出系統(tǒng)的重要因素： 結構簡單：,3.1.2 技術可行性分析,3.1.3 法律可行性分析,3.1.4 開發(fā)方案可行性分析研究,1. 提出待選方案,2. 評價待選方案,3. 確定開發(fā)方案,2020/9/5,軟件工程方法,5,3.1.5 可行性分析報告文檔格式,2020/9/5,軟件工程方法,6,3.2 客戶需求分析與用例建模,用例驅動是統(tǒng)一過程的重要概念，或者說整個軟件生產過程就是用例驅動的。 分析、設計、實現(xiàn)、測試都是用例驅動的，都是以實現(xiàn)用例為目標。 用例的捕獲手段抽象,2020/9/5,軟件工程方法,7,3.2.1

3、 建造需求模型用例建模,用例建模的主要目標是： 將需求規(guī)約變?yōu)榭梢暬Ｐ?，并得到用戶確認； 給出清晰、一致的關于系統(tǒng)做什么的描述，確定系統(tǒng)的功能要求； 提供從功能需求到系統(tǒng)分析、設計、實現(xiàn)各階段的度量標準； 為最終系統(tǒng)測試提供基準，據(jù)此驗證系統(tǒng)是否達到功能要求； 為項目目標進度管理和風險管理提供依據(jù)。,2020/9/5,軟件工程方法,8,用例建模的步驟,確定系統(tǒng)的范圍和邊界； 確定系統(tǒng)的執(zhí)行者和用例； 對用例進行描述； 定義用例之間的關系； 審核用例模型。,2020/9/5,軟件工程方法,9,3.2.2 用例圖,2020/9/5,軟件工程方法,10,找出系統(tǒng)中的執(zhí)行者和用例,這項任務通常是由與

4、潛在用戶會見的系統(tǒng)分析員完成的。 在某些情況下，該任務還包括你與顧客面對面的訪談，在訪談中可以提出問題，了解他們的需求。訪談過程中，你可以整理出一個手抄本，或者簡單地多做些記錄以備后用。 在另外一些情況下，公司中的一些人會向你提供項目的業(yè)務需求列表。對于這些業(yè)務需求，你需要向提供者提出一些問題以得到你所需要的答案。這些需求和你得到的答案將成為創(chuàng)建用例圖的筆記。,2020/9/5,軟件工程方法,11,3.2.3 定義系統(tǒng)的邊界和范圍,系統(tǒng)邊界包括： 整個組織：如一個企業(yè)； 一個組織的某個部門：如企業(yè)的財務處； 計算機系統(tǒng)的硬件/軟件邊界：如企業(yè)的進、銷、存計算機管理系統(tǒng)。 1定義系統(tǒng)的范圍 2定

5、義系統(tǒng)的邊界,2020/9/5,軟件工程方法,12,3.2.4 確定執(zhí)行者(參與者),執(zhí)行者（actor）是指在系統(tǒng)外部與系統(tǒng)交互的人或其他系統(tǒng)，他以某種方式參與了系統(tǒng)內用例的執(zhí)行。 Actor：在系統(tǒng)之外與系統(tǒng)交互的某人或某事物。 Actor在建模過程中是處于核心地位的。,2020/9/5,軟件工程方法,13,2020/9/5,軟件工程方法,14,14,誰是執(zhí)行者？,小王去銀行開戶，向大廳經(jīng)理詢問了辦理手續(xù)，填寫了表單，交給柜臺職員，拿到了銀行存折。,2020/9/5,軟件工程方法,15,回答問題,誰對系統(tǒng)有著明確的目標和要求并且主動發(fā)出動作？ 系統(tǒng)是為誰服務的？,2020/9/5,軟件工程

6、方法,16,參與者 業(yè)務工人,2020/9/5,軟件工程方法,17,執(zhí)行者可以非人,需求：每天自動統(tǒng)計網(wǎng)頁訪問量，生成統(tǒng)計報表，并發(fā)送至管理員信箱。 原則： 不存在沒有參與者的用例，用例不應該自動啟動，也不應該主動啟動另一個用例。,2020/9/5,軟件工程方法,18,1定義執(zhí)行者時應注意的幾個問題,（1）執(zhí)行者之間可以有繼承關系 （2）執(zhí)行者代表一種角色而不是具體某個人 （3）對同一個人擔任角色的限制 （4）執(zhí)行者可分成主執(zhí)行者和副執(zhí)行者 （5）執(zhí)行者還可細分為主動執(zhí)行者和被動執(zhí)行者,2020/9/5,軟件工程方法,19,2020/9/5,軟件工程方法,20,2尋找和確定執(zhí)行者,2020/9

7、/5,軟件工程方法,21,情況一,2020/9/5,軟件工程方法,22,情況二,2020/9/5,軟件工程方法,23,情況三,2020/9/5,軟件工程方法,24,情況四,2020/9/5,軟件工程方法,25,3.2.5 確定用例,用例，就是一件事情，要完成這件事情，需要做一系列的活動；而做一件事情可以有很多不同的方法和步驟，也可能會遇到各種各樣的意外情況，因此這件事情是由很多不同情況的集合構成的，在UML中我們稱之為場景。一個場景就是一個用例的實例。,2020/9/5,軟件工程方法,26,3.2.5.確定用例1.用例的特征,響應性。一個用例不自動執(zhí)行，總是有執(zhí)行者啟動。 回執(zhí)性。 用例執(zhí)行完

8、畢，向執(zhí)行者提供可識別的返回值。 完整性。 用例表示一個完整的功能，必須是一完整的描述。 必須以向執(zhí)行者提供返回值作為該用例完整性的標志。,2020/9/5,軟件工程方法,27,用例的特征-響應性,這件事必須由一個執(zhí)行者發(fā)起，執(zhí)行者的愿望是用例存在的原因。不存在沒有執(zhí)行者的用例，也不應該主動啟動另一個用例。,2020/9/5,軟件工程方法,28,用例的特征-完整性,用例是相對獨立的，即用例的“功能”是完備的,2020/9/5,軟件工程方法,29,一個用例就是一個需求單元、分析單元、設計單元、開發(fā)單元、測試單元甚至部署單元。,2020/9/5,軟件工程方法,30,用例的特征-回執(zhí)性,用例的執(zhí)行結

9、果對執(zhí)行者來說是可觀測和有意義的,2020/9/5,軟件工程方法,31,用例的執(zhí)行結果對參與者來說是可觀測的和有意義的。 如，系統(tǒng)會監(jiān)控參與者在系統(tǒng)里的操作，并在參與者刪除數(shù)據(jù)之前備份。雖然它是系統(tǒng)的一個必需組成部分，但它在需求階段卻不應該作為用例出現(xiàn)。 因為這是一個后臺進程，對參與者來說是不可觀測的，它應該在系統(tǒng)用例分析階段定義。 又比如，登錄系統(tǒng)是一個有效的用例，但輸入密碼卻不是。這是因為登錄系統(tǒng)對參與者是有意義的，這樣他可以獲得身份認證和授權，但輸入密碼卻是沒有意義的，輸入完了呢？有什么結果嗎？,2020/9/5,軟件工程方法,32,用例的特征-動賓短語,用例必然是以動賓短語形式出現(xiàn)的。

10、,2020/9/5,軟件工程方法,33,用例必然是以動賓短語形式出現(xiàn)的。即，這件事必須有一個動作和動作的受體。 例如，喝水是一個有效的用例，而“喝”和“水”卻不是。雖然生活常識告訴我們，在沒有水的情況下人是不會做出喝這個動作的，水也必然是喝進去的，而不是滑進去的. 但是我們所見的很多用例中類似“計算”，“統(tǒng)計”，“報表”，“輸出”，“錄入”之類的并不在少數(shù)。,2020/9/5,軟件工程方法,34,3.2.5.2.尋找和確定用例,業(yè)務用例：開始階段，在確定用戶需求過程中，系統(tǒng)分析員通過與客戶交流建立業(yè)務模型來發(fā)現(xiàn)和確定的用例。 系統(tǒng)用例：系統(tǒng)構造階段，系統(tǒng)分析和設計人員在進行系統(tǒng)分析和設計時，根

11、據(jù)系統(tǒng)的需求建立的用例。,2020/9/5,軟件工程方法,35,在系統(tǒng)開發(fā)的開端階段，應把注意力集中在業(yè)務用例上，在精化階段和構建階段再考慮系統(tǒng)用例,2020/9/5,軟件工程方法,36,建立用例模型時，可詢問：,用戶(執(zhí)行者)需要系統(tǒng)提供哪些業(yè)務功能,即系統(tǒng)能做什么? 用戶最關心系統(tǒng)中哪些事件?從功能觀點看,這些事件表示什么? 用戶要了解系統(tǒng)在工作中發(fā)生了哪些事件及其結果? 用戶自己需要做什么? 用戶是否要在系統(tǒng)中創(chuàng)建、刪除、讀、修改或存儲某類業(yè)務數(shù)據(jù)？ 系統(tǒng)為了維持正常運轉需要增加的功能和信息的交互； 這些信息從何而來，到哪里去？ 實現(xiàn)當前系統(tǒng)（可能是人工系統(tǒng)而不是自動化系統(tǒng)）的關鍵問題是

12、什么？,2020/9/5,軟件工程方法,37,通過與用戶反復交流，確定主要業(yè)務用例和次要業(yè)務用例。 對于建立的每一個業(yè)務用例，都需要一組系統(tǒng)用例來輔助和支持。（不嚴謹） 系統(tǒng)用例是執(zhí)行者與系統(tǒng)的交互，它描述了系統(tǒng)的功能需求和動態(tài)行為。 系統(tǒng)用例用于建立系統(tǒng)用例模型，可通過分析系統(tǒng)的業(yè)務流和控制流來尋找和確定系統(tǒng)用例。（活動圖）,2020/9/5,軟件工程方法,38,如何獲得用例訪談,您對系統(tǒng)有什么期望？ 您打算在這個系統(tǒng)里面做些什么事情？ 您做這件事的目的是什么？ 您做完這件事情希望有一個什么樣的結果？ 一個明確的有效地目標才是一個用例的來源。 一個真實的目標應當完備地表達執(zhí)行者的期望。 一個

13、有效地目標應當在系統(tǒng)邊界內，由主角發(fā)動，并具有明確的后果。,2020/9/5,軟件工程方法,39,應當先建立業(yè)務用例模型，然后再從業(yè)務用例模型向系統(tǒng)用例模型映射。 注意用例圖的層次，從系統(tǒng)到子系統(tǒng)逐層建立用例圖。,2020/9/5,軟件工程方法,40,用例和功能的誤區(qū),用例就是功能劃分？ 在描述一個事物的時候，我們可以從以下三個觀點出發(fā)： 這個事物是什么？結構性觀點 這個事物能做什么？功能性觀點 人們能用這個事物做什么？使用者觀點,2020/9/5,軟件工程方法,41,結構性觀點：自行車是一種交通工具，它由傳動系統(tǒng)、剎車系統(tǒng)等部分組成。 功能性觀點：自行車可以騎行。 使用者觀點：人們可以用雙腳

14、蹬動踏板而向前行進，可以用手捏合剎車使自行車停下來。,2020/9/5,軟件工程方法,42,總結： 功能是脫離使用者的愿望而存在的。 功能是孤立的，給一個輸入，通過計算就有一個固定的輸出只要按下開關燈就亮。 用例是系統(tǒng)性的，它需要描述誰在什么情況下通過什么方式開燈，結果是什么。 功能描述的是一個個點。 用例描述的是一個系統(tǒng)性工作。,2020/9/5,軟件工程方法,43,目標和步驟的誤區(qū),2020/9/5,軟件工程方法,44,用例的粒度,ATM取錢的場景中，取錢，讀卡，驗證賬號，打印回執(zhí)單等都是可能的用例？ 用例粒度的劃分最標準的方法應該是：以該用例是否完成了參與者的某個完整目的為依據(jù)的。 同一

15、個需求階段，用例的粒度應該時同一級別的。 粒度選取的問題本質上還是因為邊界認定不同而產生的。,2020/9/5,軟件工程方法,45,ATM示例,客戶代表說：我希望這臺ATM能支持跨行業(yè)務，我插入卡片輸入密碼后，可以讓我選擇是取錢還是存錢；為了方便，可以設置一些默認的存取金額按鈕；我可以修改密碼，也可以掛失；還有我希望可以交納水費、電費和電話等費用；為了安全起見，ATM上應當有警示小心騙子的提示條，還有攝像頭；如果輸入三次密碼錯誤，卡片應當被自動吞沒。,2020/9/5,軟件工程方法,46,判斷題,支持跨行業(yè)務 插入卡片 輸入密碼 選擇服務 取錢 存錢 掛失卡片 交納費用 警示騙子 三次錯誤吞沒

16、卡片,2020/9/5,軟件工程方法,47,判斷題參考答案,支持跨行業(yè)務錯，這是一個業(yè)務規(guī)則，限定業(yè)務的范圍 插入卡片錯，這是一個過程步驟，不是完整目標 輸入密碼錯，這是一個過程步驟，不是完整目標 選擇服務錯，這是一個過程步驟，不是完整目標 取錢對，這是一個完整有效的目標 存錢對，這是一個完整有效的目標 掛失卡片對，這是一個完整有效的目標 交納費用對，這是一個完整有效的目標 警示騙子錯，已超出了邊界范圍 三次錯誤吞沒卡片錯，這是一個業(yè)務規(guī)則，限定業(yè)務的范圍,2020/9/5,軟件工程方法,48,3.2.5.3.描述用例,用例名： 簡單名： 路徑名：,2020/9/5,軟件工程方法,49,用例的

17、文字描述應包括以下內容:,用例的目的（功能）； 該用例在什么情況下被哪個執(zhí)行者啟動執(zhí)行； 用例與執(zhí)行者之間交互哪些消息來通知對方作出決定； 交互的主消息流及因此被使用或修改的實體； 用例中可供選擇的異常事件流； 用例結束標志：給執(zhí)行者返回一個可識別的值。,2020/9/5,軟件工程方法,50,舉例,用例名稱：學生選課 執(zhí)行者：學生 目的：完成一次學生選課的完整過程。 類型：主要的、基本的 級別：一級 過程描述： （1）學生輸入標識碼（ID），系統(tǒng)識別標識碼的有效性； （2）對學生進行注冊識別； （3）流覽本學期預開課程； （4）選擇學生自己要上的課程并確認； （5）退出系統(tǒng)，系統(tǒng)給出所選課程列

18、表及相應學分合計。,2020/9/5,軟件工程方法,51,異常事件流處理： （1）標識碼有效性檢查失敗，允許學生重新輸入（3次機會）。 （2）注冊識別失敗，沒有注冊（尙未交學費）的學生不能選課。 （3）選擇課程確認失敗，所選幾門課程中在上課時間上發(fā)生沖 突時，系統(tǒng)提示重選。,2020/9/5,軟件工程方法,52,3.2.6 用例之間的關聯(lián),1繼承關聯(lián) 2.擴展關聯(lián) 3.包含關聯(lián) 4.使用關聯(lián),2020/9/5,軟件工程方法,53,1.繼承關聯(lián)-泛化(generalization),當多個用例共同擁有一種類似的結構和行為的時候 我們可以將它們的共性抽象成為父用例，其他的用例 作為泛化關系中的子用

19、例。,2020/9/5,軟件工程方法,54,泛化舉例（一）：,2020/9/5,軟件工程方法,55,泛化舉例（二）：,2020/9/5,軟件工程方法,56,2.擴展(extend),箭頭指向的用例為被擴展的用例，稱為擴展用例；箭頭出發(fā)的用例為基本用例。 擴展用例是可選的，如果缺少擴展用例，不會影響到基用例的完整性；擴展用例在一定條件下才會執(zhí)行，并且其執(zhí)行會改變基用例的行為。,2020/9/5,軟件工程方法,57,擴展(extend),將擴展用例的事件流在一定的條件下按照相應的擴展點插入到基礎用例中。 基礎用例不必知道擴展用例的任何細節(jié)，它僅為其提供擴展點。 擴展用例的行為是否被執(zhí)行要取決于主事

20、件流中的判定點。,2020/9/5,軟件工程方法,58,擴展(extend),2020/9/5,軟件工程方法,59,擴展(extend),擴展舉例（一）：,2020/9/5,軟件工程方法,60,擴展(extend),擴展舉例（二）：,2020/9/5,軟件工程方法,61,3.包含(include),包含是指基本用例(base use case)會用到包含用例(inclusion)，具體地講，就是將包含用例的事件流插入到基礎用例的事件流中。包含用例是可重用的用例多個用例的公共用例。,2020/9/5,軟件工程方法,62,包含(include),箭頭指向的用例為被包含的用例，稱為包含用例；箭頭出發(fā)

21、的用例為基本用例。 包含用例是必選的，如果缺少包含用例，基礎用例就不完整；包含用例必須被執(zhí)行，不需要滿足某種條件；其執(zhí)行并不會改變基用例的行為。,2020/9/5,軟件工程方法,63,包含(include),2020/9/5,軟件工程方法,64,包含(include),包含舉例（一）：,2020/9/5,軟件工程方法,65,包含(include),包含舉例（二）：,2020/9/5,軟件工程方法,66,用例之間的關系,包含用例與擴展用例的區(qū)別 相對于基礎用例，擴展用例是可選的，而包含用例則不是。 如果缺少擴展用例，基礎用例還是完整的，而缺少包含用例，則基礎用例就不完整了。 擴展用例的執(zhí)行需要滿

22、足某種條件，而包含用例不需要。 擴展用例的執(zhí)行會改變基礎用例的行為，而包含用例不會。,2020/9/5,軟件工程方法,67,使用關聯(lián),使用關聯(lián)也是一種繼承關系. 在使用關聯(lián)中,一個用例使用另一個用例的功能和行為.,2020/9/5,軟件工程方法,68,考慮用例的關聯(lián)類型,2020/9/5,軟件工程方法,69,2020/9/5,軟件工程方法,70,1).圖中的參與者有？ (a) 1 (b) 2 (c) 3 (d) 4 2).圖中的用例有？ (a) 1 (b) 2 (c) 3 (d) 4 3). 2和3之間是什么關系？5和6呢？ (a) 擴展，包含(b) 包含，擴展 4).5缺少了3仍然是個完整的

23、用例？ (a) 是的(b) 不是 5).4能夠參與2嗎？1能夠參與5嗎？ (a) 可以，不可以 (b) 不可以，可以,習題答案： 1、(a)(d) 2、(b)(c) 3、(b) 4、(b) 5、(b),習題,2020/9/5,軟件工程方法,71,3.2.7 用例圖實例,2020/9/5,軟件工程方法,72,3.3 定義系統(tǒng)的對象和類(第4章講) 類-責任-協(xié)作者（簡稱CRC）技術.,2020/9/5,軟件工程方法,73,3.4 客戶需求分析規(guī)格說明,2020/9/5,軟件工程方法,74,補充知識點：ROSE用例視圖,在Rose用例視圖中，可建立系統(tǒng)的用例模型，它包含所有的角色、用例、用例圖，還

24、可能包含一些描述用例功能的順序圖、活動圖。 Rose用例模型分成兩個層次： 業(yè)務用例模型（Business Use Case Model） 系統(tǒng)用例模型（System Use Case Model） 業(yè)務用例模型關注的是企業(yè)的業(yè)務功能，系統(tǒng)建立前的組織機構、角色和他們之間的相互關系，即機構內部實際業(yè)務工作流。 系統(tǒng)用例模型是針對將創(chuàng)建的系統(tǒng)描述其功能需求。 用例圖模型只是描述系統(tǒng)及其功能需求，不考慮系統(tǒng)設計與實現(xiàn)。,2020/9/5,軟件工程方法,75,建立業(yè)務用例模型的目的： 了解企業(yè)的組織機制； 了解企業(yè)組織中當前存在的問題并確定改進的可能性； 確?？蛻簟⒆罱K用戶和開發(fā)人員就企業(yè)業(yè)務流程達

25、成共識； 描述企業(yè)部門的業(yè)務功能。,一、業(yè)務用例模型,業(yè)務用例模型是企業(yè)最核心、最概括的業(yè)務說明，主要由以下兩部分組成。 業(yè)務角色和業(yè)務員工。一個角色既可以是一個用戶，也可以是一個信息系統(tǒng)。業(yè)務角色是機構外部與機構交互的對象，業(yè)務角色與企業(yè)的業(yè)務活動有關；業(yè)務員工是機構內部的角色，通過描述每個業(yè)務員工，可以了解這些角色在系統(tǒng)中的責任和活動。,1、業(yè)務用例模型的組成,2020/9/5,軟件工程方法,76,2、業(yè)務用例模型的基本元素,業(yè)務用例。業(yè)務用例是機構中的一組相關工作流。機構中的全部用例一起完整地描述了企業(yè)的業(yè)務目標。這些業(yè)務用例是建立新系統(tǒng)的功能需求。,2020/9/5,軟件工程方法,77

26、,（l）業(yè)務角色（BusinessActor） 業(yè)務角色是與企業(yè)機構交互的一切人或系統(tǒng)。業(yè)務角色不包含單位機構內部人員。 （2）業(yè)務員工（BusinessWorker） 業(yè)務員工是企業(yè)機構內部人員，代表業(yè)務中的一個或一組角色。業(yè)務員工參與業(yè)務用例實現(xiàn)時，業(yè)務員工和業(yè)務用例進行交互，并使用和控制業(yè)務實體。 （3）業(yè)務用例（BusinessUseCase） 業(yè)務用例是企業(yè)中的一組相關工作流，對業(yè)務角色提供服務。業(yè)務用例描述告訴人們單位機構做什么，以及做什么會有利于業(yè)務和參與人員的工作，單位中的全部業(yè)務用例一起完整地描述業(yè)務目標。 （4）業(yè)務實體（Business Entity） 業(yè)務實體也被稱為業(yè)務對象（Business Object） 業(yè)務實體代表業(yè)務角色中處理或使用的“事物”。例如