1、軟件需求概論,2,第6章 需求分析與建模最佳實(shí)踐,6.1 需求分析與建模的要點(diǎn) 與誤區(qū)分析 6.2 周期一:理清框架與脈絡(luò) 6.3 周期二：確定需求細(xì)節(jié) 6.4 其他需求分析,需求分析是需求工程中最為核心的工作 ，而需求建模則是需求分析的主要手段。,3,6.1 需求分析與建模的要點(diǎn) 與誤區(qū)分析,6.1.1 需求分析到底做什么 6.1.2 建模的目標(biāo)與要點(diǎn) 6.1.3 選擇建模工具的要點(diǎn),4,6.1.1 需求分析到底做什么,需求分析是業(yè)務(wù)分析，也就是選擇一種業(yè)務(wù)導(dǎo)向的線索將零散的需求串起來，形成一個(gè)體系完整、內(nèi)容清晰的框架，以指導(dǎo)后續(xù)的設(shè)計(jì)、開發(fā)工作。 概括為：分解、提煉、消除矛盾,5,需求分析

2、到底做什么之一：分解,分解：自頂向下的方法 現(xiàn)代需求工程理論更建議采用業(yè)務(wù)導(dǎo)向的分解，而非傳統(tǒng)的系統(tǒng)導(dǎo)向的分解。 分解結(jié)構(gòu)類型 (1)業(yè)務(wù)流程為主線索的分解結(jié)構(gòu) 聯(lián)機(jī)事務(wù)處理系統(tǒng)、管理信息系統(tǒng)適用。 (2)程序結(jié)構(gòu)為主線索的分解結(jié)構(gòu) 適用于問題域不復(fù)雜或者系統(tǒng)與問題域關(guān)聯(lián)性不強(qiáng)的情況。,6,6.1.1 需求分析到底做什么,(3)基于場(chǎng)景的分解結(jié)構(gòu) 適用于決策支持系統(tǒng)、面向用戶的嵌入式系統(tǒng) (4)基于數(shù)據(jù)的分解結(jié)構(gòu) 適用于諸如數(shù)據(jù)倉庫之類的數(shù)據(jù)類項(xiàng)目 選擇了一個(gè)合適的分解結(jié)構(gòu)之后，就可以把需求規(guī)格說明書的大綱確定下來，知道應(yīng)該捕獲什么信息；因此當(dāng)信息捕獲回來后，需求分析的任務(wù)就是將其填充到相應(yīng)的

3、級(jí)別上，并不斷驗(yàn)證是否已經(jīng)填充完成。,7,需求分析到底做什么之二：提煉,提煉：自底向上的方法 分解是一種自頂向下的方法，當(dāng)你按任何一種線索進(jìn)行分解時(shí)，就會(huì)破壞其他線索的完整性。例如，如果以“事”為線索，那么會(huì)發(fā)現(xiàn)數(shù)據(jù)需求分解后就會(huì)出現(xiàn)相互交疊的情況，也就是在多個(gè)業(yè)務(wù)事件中都涉及相同的類。 當(dāng)出現(xiàn)這樣的現(xiàn)象時(shí)就會(huì)阻礙需求分析人員建立全面理解，因此我們還需要采用自底向上的方法進(jìn)行提煉。,8,需求分析到底做什么之三：消除矛盾,在分析過程中，顯然會(huì)發(fā)現(xiàn)有些需求是相互矛盾、相互沖突的。由于你是在把收集的信息放在一個(gè)預(yù)先定義的結(jié)構(gòu)中發(fā)現(xiàn)這些矛盾的，因此對(duì)矛盾的影響范圍會(huì)有直觀的了解，也知道它影響到哪些層面

4、。這樣，你就可以很快地找到相應(yīng)的人員，通過進(jìn)一步的捕獲來消除矛盾。,9,6.1.2 建模的目標(biāo)與要點(diǎn),建模是需求分析的主要手段，它通過簡化、強(qiáng)調(diào)來幫助需求分析人員理清思路，達(dá)成共識(shí) 1.建模的目的 幫助我們按照實(shí)際情況或按我們需要的樣式對(duì)系統(tǒng)進(jìn)行可視化； 提供一種詳細(xì)說明系統(tǒng)的結(jié)構(gòu)或行為的方法； 給出一個(gè)指導(dǎo)系統(tǒng)構(gòu)造的模板； 對(duì)我們所做出的決策進(jìn)行文檔化。,10,6.1.2 建模的目標(biāo)與要點(diǎn),2建模的要點(diǎn)與原則 要點(diǎn)： 設(shè)計(jì)要考慮到計(jì)劃之外的變化； 設(shè)計(jì)要文檔化； 用可視化的模型表達(dá)架構(gòu)，有助于理解變化所代表的含義。 原則：模型是用來溝通的，需要時(shí)才構(gòu)建。,11,6.1.3選擇建模工具的要點(diǎn),

5、1正確認(rèn)識(shí)建模方法論,12,6.1.3選擇建模工具的要點(diǎn),2正確認(rèn)識(shí)UML UML是一種Language(語言) ！ UML是一種Modeling(建模)Language! UML是一種Unified(統(tǒng)一)Modeling Language！ 如何選擇UML圖 ？,13,第6章 需求分析與建模最佳實(shí)踐,6.1 需求分析與建模的要點(diǎn)與誤區(qū)分析 6.2 周期一:理清框架與脈絡(luò) 6.3 周期二：確定需求細(xì)節(jié) 6.4 其他需求分析,14,6.2 周期一:理清框架與脈絡(luò),6.2.1 業(yè)務(wù)流程分析 6.2.2 業(yè)務(wù)實(shí)體分析 6.2.3 角色與使用場(chǎng)景分析 6.2.4 周期一的產(chǎn)物,15,6.2 周期一:

6、理清框架與脈絡(luò),16,6.2.1 業(yè)務(wù)流程分析,這個(gè)階段的任務(wù)是理清需求的結(jié)構(gòu)框架(領(lǐng)域類圖)和行為脈絡(luò)(流程圖和用例圖) 該工作的輸入是需求定義階段產(chǎn)生的業(yè)務(wù)事件列表和報(bào)表列表，輸出的是領(lǐng)域模型和用例模型 在整個(gè)過程中是針對(duì)每個(gè)業(yè)務(wù)事件進(jìn)行業(yè)務(wù)流程分析、業(yè)務(wù)實(shí)體分析和用例分析；針對(duì)每類報(bào)表業(yè)務(wù)實(shí)體分析和用例分析。,17,6.2.1 業(yè)務(wù)流程分析,業(yè)務(wù)流程分析是針對(duì)每個(gè)業(yè)務(wù)事件來進(jìn)行的，業(yè)務(wù)事件是業(yè)務(wù)流程的觸發(fā)，沿著對(duì)業(yè)務(wù)事件的響應(yīng)序列，找到所有相關(guān)的業(yè)務(wù)活動(dòng)，表述出這些業(yè)務(wù)活動(dòng)之間的關(guān)系就是該任務(wù)的關(guān)鍵目標(biāo)。 在業(yè)務(wù)流程分析中，信息的主要來源是負(fù)責(zé)該業(yè)務(wù)流程的中層管理人員，因此訪談的對(duì)象就是

7、這一類人員。具體來說，它就是針對(duì)每一個(gè)業(yè)務(wù)事件，分析并識(shí)別現(xiàn)有業(yè)務(wù)活動(dòng)，確定業(yè)務(wù)活動(dòng)之間的關(guān)系；了解這些業(yè)務(wù)活動(dòng)需要接受哪些信息，將產(chǎn)生哪些數(shù)據(jù)(表單)，確定數(shù)據(jù)傳送的路線；同時(shí)標(biāo)識(shí)出業(yè)務(wù)活動(dòng)是由哪些部門、崗位負(fù)責(zé)等信息。 在分析過程中，要注意抓住核心業(yè)務(wù)和主要活動(dòng)點(diǎn)、部門內(nèi)以及部門之間的銜接，工作中的煩瑣及反復(fù)的環(huán)節(jié)，成本高、效率低、時(shí)間長的環(huán)節(jié)以及任務(wù)轉(zhuǎn)手次數(shù)較多的環(huán)節(jié)。,18,1. 業(yè)務(wù)流程分析的要點(diǎn)與產(chǎn)物,關(guān)鍵的要點(diǎn)： 一是理解流程的層次性； 三大層次 ：組織級(jí)，部門級(jí) ，崗位級(jí) 二是了解流程的類型； 生產(chǎn)性流程，管理性流程，支持性流程 三是掌握以業(yè)務(wù)事件識(shí)別、尋找流程的技巧。 流程分

8、析產(chǎn)物，最常使用的模型有三種：跨職責(zé)流程圖、活動(dòng)圖和數(shù)據(jù)流圖。,19,2. 跨職責(zé)流程圖應(yīng)用基礎(chǔ)與要點(diǎn),跨職責(zé)流程圖是商業(yè)建模的標(biāo)準(zhǔn)工具，它定義了一套標(biāo)準(zhǔn)的建模元素和建模方法 . (1)跨職責(zé)流程圖的主要元素 流程名稱 職責(zé)帶區(qū) 流程階段 流程元素 并行 流程引用,20,2. 跨職責(zé)流程圖應(yīng)用基礎(chǔ)與要點(diǎn),(2)繪制要點(diǎn) 在進(jìn)行業(yè)務(wù)流程分析時(shí)，關(guān)鍵的入手點(diǎn)是部門級(jí)的業(yè)務(wù)流程，也就是從業(yè)務(wù)事件出發(fā)，分析該業(yè)務(wù)事件會(huì)觸發(fā)的一系列活動(dòng)。要真正保障繪制出來的跨職責(zé)流程圖是真實(shí)、有效的，就必須強(qiáng)化用戶的參與。 具體來說，我們應(yīng)該先找到業(yè)務(wù)事件的負(fù)責(zé)人，然后通過設(shè)問的方式，讓他描述響應(yīng)該業(yè)務(wù)事件所進(jìn)行的活動(dòng)

9、，說明活動(dòng)的執(zhí)行崗位以及它們之間的關(guān)系、數(shù)據(jù)傳遞。,21,跨職責(zé)流程圖的繪制示例,每年初將由航標(biāo)站根據(jù)本年度的計(jì)劃任務(wù)，并結(jié)合上一年度的情況制訂新年度計(jì)劃，形成向航標(biāo)處業(yè)務(wù)部門提交的工作計(jì)劃。 航標(biāo)處業(yè)務(wù)部門對(duì)其工作計(jì)劃進(jìn)行審核，同時(shí)上報(bào)處計(jì)劃部門，計(jì)劃部門對(duì)其進(jìn)行反饋。航標(biāo)處業(yè)務(wù)部門進(jìn)行補(bǔ)充，形成“工作計(jì)劃”上報(bào)處領(lǐng)導(dǎo)。由航標(biāo)處領(lǐng)導(dǎo)對(duì)其進(jìn)行審核與確認(rèn)，并形成“工作任務(wù)”下發(fā)給養(yǎng)護(hù)中心。 然后再由養(yǎng)護(hù)中心安排具體的采購計(jì)劃。采購計(jì)劃生成后報(bào)航標(biāo)處領(lǐng)導(dǎo)審批后進(jìn)行采購流程。,22,跨職責(zé)流程圖的繪制示例,23,3. 活動(dòng)圖應(yīng)用基礎(chǔ)與要點(diǎn),(1)活動(dòng)圖概述 活動(dòng)圖是一種表述過程機(jī)理、業(yè)務(wù)過程以及工作

10、流的技術(shù)。它可以用來對(duì)業(yè)務(wù)過程、工作流建模，也可以對(duì)用例實(shí)現(xiàn)甚至是程序?qū)崿F(xiàn)來建模。 (2)活動(dòng)圖的主要元素(最主要的幾種建模元素 ) 初始節(jié)點(diǎn)和活動(dòng)終點(diǎn) 活動(dòng)節(jié)點(diǎn) 轉(zhuǎn)換 分支與監(jiān)護(hù)條件 分岔與匯合,24,3. 活動(dòng)圖應(yīng)用基礎(chǔ)與要點(diǎn),(3)帶泳道的活動(dòng)圖 (4)帶對(duì)象流的活動(dòng)圖 (5)復(fù)雜活動(dòng)圖 輔助活動(dòng)圖 匯合描述 發(fā)送信號(hào)與接收信號(hào) 引腳(pin) 擴(kuò)展區(qū)(Expansion Region) (6)繪制活動(dòng)圖之后,25,4.數(shù)據(jù)流圖應(yīng)用基礎(chǔ),數(shù)據(jù)流圖(DFD)是一種歷史悠久的建模方法，它對(duì)于數(shù)據(jù)流為主線索的處理過程是最合適的，例如計(jì)費(fèi)系統(tǒng)。 (1)數(shù)據(jù)流圖的主要元素,26,4.數(shù)據(jù)流圖應(yīng)用基

11、礎(chǔ),(2)分層的數(shù)據(jù)流圖 數(shù)據(jù)流圖模型中引入了層次結(jié)構(gòu)的數(shù)據(jù)流程圖。 它是按照系統(tǒng)的層次結(jié)構(gòu)進(jìn)行逐級(jí)分解的，以分層的數(shù)據(jù)流圖來反映這種結(jié)構(gòu)關(guān)系,27,以下是繪制數(shù)據(jù)流圖的一些約定規(guī)則： 過程通過數(shù)據(jù)存儲(chǔ)區(qū)進(jìn)行通信，而不是從一個(gè)過程直接流到另一個(gè)過程。 使用數(shù)據(jù)流圖時(shí)，不要試圖讓數(shù)據(jù)流圖反映處理順序。 用簡明的動(dòng)詞短語命名每一個(gè)過程：動(dòng)詞加對(duì)象。 過程的編號(hào)要惟一且具有層次性。 在單個(gè)圖中繪制的過程不要超過810個(gè)，否則就很難繪制、更改和理解它。 與圓圈相連的數(shù)據(jù)流不允許只有輸入或只有輸出。,28,4.數(shù)據(jù)流圖應(yīng)用基礎(chǔ),(3)數(shù)據(jù)流圖的繪制過程 通過標(biāo)識(shí)業(yè)務(wù)事件完成從頂層圖到0層圖的分解； 再通

12、過將業(yè)務(wù)事件分解成業(yè)務(wù)活動(dòng)實(shí)現(xiàn)0層圖到1層圖的細(xì)化； 然后就是通過將業(yè)務(wù)活動(dòng)分解成業(yè)務(wù)步驟實(shí)現(xiàn)1層圖到2層圖的分解。,29,4.數(shù)據(jù)流圖應(yīng)用基礎(chǔ),(3)數(shù)據(jù)流圖的繪制過程 構(gòu)建頂層圖“課程注冊(cè)系統(tǒng)”,30,4.數(shù)據(jù)流圖應(yīng)用基礎(chǔ),(3)數(shù)據(jù)流圖的繪制過程 根據(jù)業(yè)務(wù)事件繪制DFD片段,31,根據(jù)業(yè)務(wù)事件繪制DFD片段,32,4.數(shù)據(jù)流圖應(yīng)用基礎(chǔ),(3)數(shù)據(jù)流圖的繪制過程 將DFD片片段合并成DFD,33,4.數(shù)據(jù)流圖應(yīng)用基礎(chǔ),(3)數(shù)據(jù)流圖的繪制過程 逐步細(xì)化，分解到底,34,622 業(yè)務(wù)實(shí)體分析,在業(yè)務(wù)流程中，必須會(huì)涉及許多業(yè)務(wù)實(shí)體(或稱為業(yè)務(wù)數(shù)據(jù)、業(yè)務(wù)術(shù)語)，要正確地構(gòu)建出信息系統(tǒng)，就必須對(duì)這

13、些業(yè)務(wù)實(shí)體建立正確的認(rèn)識(shí)。 具體來說，就是要了解這個(gè)問題域中有哪些業(yè)務(wù)實(shí)體，它們之間存在什么樣的邏輯關(guān)系、數(shù)量關(guān)系，以及有什么相應(yīng)的結(jié)構(gòu)規(guī)則。實(shí)際上這樣的工作就是大名鼎鼎的“領(lǐng)域建?！?、“概念建?！?。,35,1業(yè)務(wù)實(shí)體分析任務(wù)概述,在領(lǐng)域建模的過程中，應(yīng)該更多地采用“自底向上”的方法； 針對(duì)每一個(gè)業(yè)務(wù)事件、每一類報(bào)表創(chuàng)建局部的領(lǐng)域類圖片段，然后當(dāng)完成這些建模工作之后，再對(duì)其進(jìn)行抽象、提煉，形成全局的領(lǐng)域模型。 針對(duì)每一個(gè)業(yè)務(wù)事件、每一類報(bào)表進(jìn)行領(lǐng)域類圖片段的繪制時(shí)，其主要的步驟包括三個(gè)： 識(shí)別出業(yè)務(wù)實(shí)體， 確定實(shí)體之間的關(guān)系(語義關(guān)系和數(shù)量關(guān)系)， 定義實(shí)體的關(guān)鍵屬性。,36,1業(yè)務(wù)實(shí)體分析任

14、務(wù)概述,業(yè)務(wù)實(shí)體分析的產(chǎn)物有兩種可選的模型： 類圖 E/R模型也叫實(shí)體關(guān)系圖,37,2.類圖應(yīng)用基礎(chǔ)及要點(diǎn),38,（1）領(lǐng)域建模方法示例,領(lǐng)域建模時(shí)，其工作主要就是 標(biāo)識(shí)類 明確類之間的邏輯關(guān)系和數(shù)量關(guān)系 添加重要的結(jié)構(gòu)規(guī)則 三個(gè)方面。,39,參考案例： 個(gè)人圖書管理系統(tǒng)需求概述,小王是一個(gè)愛書之人，家里各類書籍已過千冊(cè)，而平時(shí)又時(shí)常有朋友外借，因此需要一個(gè)個(gè)人圖書管理系統(tǒng)。該系統(tǒng)應(yīng)該能夠?qū)幕拘畔从?jì)算機(jī)類、非計(jì)算機(jī)類分別建檔，實(shí)現(xiàn)按書名、作者、類別、出版杜等關(guān)鍵字的組合查詢功能。 在使用該系統(tǒng)錄入新書籍時(shí)系統(tǒng)會(huì)自動(dòng)按規(guī)則生成書號(hào)，可以修改信息，但一經(jīng)創(chuàng)建就不允許刪除。該系統(tǒng)還應(yīng)該能夠

15、對(duì)書籍的外借情況進(jìn)行記錄，可對(duì)外借情況列表打印。 還希望能夠?qū)馁徺I金額、冊(cè)數(shù)按特定時(shí)間周期進(jìn)行統(tǒng)計(jì)。,40,標(biāo)識(shí)類,發(fā)現(xiàn)類的方法有很多種： 腦力風(fēng)暴： 所謂腦力風(fēng)暴是指我們看到需求或模型后，感覺到系統(tǒng)中應(yīng)該存在哪些分析類。 詞性分析法： 所謂詞性分析法，是指我們根據(jù)需求描述或模型中的詞匯進(jìn)行分析，在分析過程中，按詞性進(jìn)行類、屬性、方法的劃分。 (領(lǐng)域模型) CRC分析法（候選類、職責(zé)、協(xié)作分析法）： CRC分析法也是一個(gè)簡單易行的分析方法。通過對(duì)那些可能的類進(jìn)行職責(zé)與協(xié)作的分析，進(jìn)一步確認(rèn)系統(tǒng)中的分析類及其屬性、方法。CRC分析法要求我們對(duì)每一個(gè)候選類做一個(gè)卡片，在卡片上對(duì)這個(gè)類進(jìn)行描述

16、，在描述的下面寫上這個(gè)類的職責(zé)，在背面寫出與這個(gè)類有協(xié)作關(guān)系的其它類及協(xié)作關(guān)系。 (領(lǐng)域模型) 根據(jù)邊界類、控制類、實(shí)體類幫助分析系統(tǒng)中的類(分析模型) 其中最廣泛應(yīng)用的莫過于“名詞動(dòng)詞法”，,41,標(biāo)識(shí)類,問題域建模的第一步-標(biāo)識(shí)類 名詞動(dòng)詞法，其主要規(guī)則是從名詞與名詞短語中提取對(duì)象與屬性； 從動(dòng)詞與動(dòng)詞短語中提取操作與關(guān)聯(lián)； 而所有格短語通常表明名詞應(yīng)該是屬性而不是對(duì)象。,42,找到備選類：,小王是一個(gè)愛書之人，家里各類書籍已過千冊(cè)，而平時(shí)又時(shí)常有朋友外借，因此需要一個(gè)個(gè)人圖書管理系統(tǒng)。該系統(tǒng)應(yīng)該能夠?qū)幕拘畔从?jì)算機(jī)類、非計(jì)算機(jī)類分別建檔，實(shí)現(xiàn)按書名、作者、類別、出版杜等關(guān)鍵字的組

17、合查詢功能。 在使用該系統(tǒng)錄入新書籍時(shí)系統(tǒng)會(huì)自動(dòng)按規(guī)則生成書號(hào)，可以修改信息，但一經(jīng)創(chuàng)建就不允許刪除。該系統(tǒng)還應(yīng)該能夠?qū)耐饨枨闆r進(jìn)行記錄，可對(duì)外借情況列表打印。 還希望能夠?qū)馁徺I金額、冊(cè)數(shù)按特定時(shí)間周期進(jìn)行統(tǒng)計(jì)。,43,決定候選類,類剔除原則： 無關(guān)緊要的類 系統(tǒng)外的類 表述的概念相對(duì)較小，適合于某個(gè)候選類的屬性 非問題域本質(zhì)類,44,“小王”、“人”、“家里”系統(tǒng)外的概念，無須對(duì)其建模； “個(gè)人圖書管理系統(tǒng)”、“系統(tǒng)”指的就是將要開發(fā)的系統(tǒng)，即系統(tǒng)本身，也無須對(duì)其進(jìn)行建模； “書籍”是一個(gè)很重要的類，而“書名”、“作者”、“類別”、“出版社”、“書號(hào)”則都是用末描述書籍的基本信息

18、的，因此應(yīng)該作為“書籍”類的屬性處理。而“規(guī)則”是指書號(hào)的生成規(guī)則，書號(hào)則是書籍的一個(gè)屬性，因此“規(guī)則”可以作為編寫“書籍”類構(gòu)造函數(shù)的指南； “基本信息”則是書名、作者、類別等描述書籍的基本信息統(tǒng)稱，“關(guān)鍵字”則是代表其中 之一，因此無須對(duì)其建模； “功能”、“新書籍”、“信息”、“記錄”都是在描述需求時(shí)使用到的一些相關(guān)詞語，并不是問題域的本質(zhì)，因此先可以將其淘汰； “計(jì)算機(jī)類”、“非計(jì)算機(jī)類”是該系統(tǒng)中圖書的兩大分類，因此應(yīng)該對(duì)其建模，并改名為 “計(jì)算機(jī)類書籍”和“非計(jì)算機(jī)類書籍”，以減少歧義；,45,“外借情況”則是用來表示一次借閱行為，應(yīng)該成為一個(gè)候選類，多個(gè)外借情況將組成“外 借情況

19、列表”，而外借情況中一個(gè)很重要的角色是“朋友”借閱主體。雖然本系統(tǒng)中并不需要建立“朋友”的資料庫，但考慮到可能會(huì)需要列出某個(gè)朋友的借閱情況，因此還是將其列為候選類。為了能夠更好地表述，將“外借情況”改名為“借閱記錄”，而將“外借情況列表”改名為“借閱記錄列表”； “購買金額”、“冊(cè)數(shù)”都是統(tǒng)計(jì)的結(jié)果，都是一個(gè)數(shù)字，因此不用將其建模，而“特定時(shí) 限”則是統(tǒng)計(jì)的范圍，也無須將其建模。不過從這里的分析中，我們可以發(fā)現(xiàn)，在該需求 描述中隱藏著一個(gè)名為“書籍列表”的關(guān)鍵類，它也就是執(zhí)行統(tǒng)計(jì)的主體,46,通過以上的分析，我們就可以得到一個(gè)候選類列表： 書籍 計(jì)算機(jī)類書籍 非計(jì)算機(jī)類書籍 借閱記錄 借閱記錄

20、列表 書籍列表,47,明確類間關(guān)系之確定關(guān)聯(lián)關(guān)系,確定關(guān)聯(lián)關(guān)系 “計(jì)算機(jī)類書籍”、“非計(jì)算機(jī)類書籍”與“書籍”之間是繼承關(guān)系 “書籍列表”則是由多個(gè)“書籍”組成的，“借閱記錄列表”是由多條“借閱記錄”組成的，這種組成關(guān)系適用于組合還是聚合關(guān)系? -聚合更合適 “借閱記錄”與“書籍”關(guān)聯(lián)關(guān)系,初始類模型,48,明確類間關(guān)系之多重性分析,加入多重性信息,49,確定類的主要職責(zé),類的職責(zé)： 類所維護(hù)的知識(shí)-類的成員變量(即屬性) 類能夠執(zhí)行的行為-成員方法（屬于行為需求領(lǐng)域，體現(xiàn)在用例模型中）,加入類的屬性,50,補(bǔ)充類之間的結(jié)構(gòu)規(guī)則,類圖中的諸如導(dǎo)航性、角色名、導(dǎo)出屬性、限定符及約束等修飾屬性 導(dǎo)

21、航性分析 “書籍”與“借閱記錄”之間存在關(guān)聯(lián)關(guān)系。它們之間是一種雙向關(guān)聯(lián) 約束 “書籍”對(duì)象創(chuàng)建后就不能夠被刪除，只能被修改，因此在Book類邊上加上了一條用自由文本寫的約束； 顯然一本書要么屬于計(jì)算機(jī)類，要么屬于非計(jì)算機(jī)類，因此在兩個(gè)“泛化”關(guān)系上增 加一個(gè)“二者取之一”的約束。,51,（2）領(lǐng)域建模的常見誤區(qū),ICONIK方法的創(chuàng)始人曾經(jīng)對(duì)領(lǐng)域建模工作總結(jié)了10大誤區(qū)一些解釋 : 立即給關(guān)聯(lián)指定多重性，確保每個(gè)關(guān)聯(lián)都有明確的數(shù)量關(guān)系 對(duì)名詞和動(dòng)詞做過度的分析，而背離初衷-“分析崩潰” 不對(duì)用例和時(shí)序圖進(jìn)行研究，就將操作分配給類 對(duì)象和類的通用程度越高，在其他項(xiàng)目中重用它們的可能性就越大?！?/p>

22、案例：模塊管理、導(dǎo)入；報(bào)表管理、導(dǎo)入】,52,（2）領(lǐng)域建模的常見誤區(qū),對(duì)于每個(gè)“整體部分”關(guān)系，就使用聚合還是組合表示而爭論不休 未對(duì)問題空間進(jìn)行建模之前，就假定一種具體的實(shí)現(xiàn)策略 將類命名為難以理解的名稱，而不是直觀的名稱 直接進(jìn)入到實(shí)現(xiàn)結(jié)構(gòu)，如友元關(guān)系和參數(shù)化類 領(lǐng)域類和關(guān)系型數(shù)據(jù)庫表之間建立一對(duì)一的映射 過早地執(zhí)行“模式化”,53,2.類圖應(yīng)用基礎(chǔ)及要點(diǎn),(3) 類模型的演化 類模型是從需求分析、設(shè)計(jì)階段不斷演化而成的，其過程如圖656所示。,54,方法4：分析模型中有3種十分有用的構(gòu)造型：實(shí)體類、控制類和邊界類,實(shí)體類：實(shí)體對(duì)象的抽象，通常來自域模型也就是現(xiàn)實(shí)世界，用來描述具體的實(shí)體

23、，通常映射到數(shù)據(jù)庫表格與文件中。 控制類：控制對(duì)象的抽象，主要用來體現(xiàn)應(yīng)用程序的執(zhí)行邏輯，將其抽象出來，可以使得變化不影響用戶界面和數(shù)據(jù)庫中的表。 邊界類：邊界對(duì)象的抽象，通常是用來完成參與者(用戶、外部系統(tǒng))與系統(tǒng)之間交互的 對(duì)象，例如From、對(duì)話框、菜單、接口等。 分析模型通常是在用例模型和領(lǐng)域模型的基礎(chǔ)上進(jìn)行綜合分析而得的。從領(lǐng)域模型中將得到實(shí)體類，而邊界類主要負(fù)責(zé)處理與用戶的交互，控制類則負(fù)責(zé)完成實(shí)際的程序邏輯。,55,實(shí)體類、控制類和邊界類,轉(zhuǎn) pdf,56,3E/R圖應(yīng)用基礎(chǔ),描述業(yè)務(wù)實(shí)體之間的關(guān)系除了可以使用類圖之外，也可以使用傳統(tǒng)的E/R模型。 優(yōu)勢(shì)：能夠更好地與后續(xù)的數(shù)據(jù)庫

24、設(shè)計(jì)結(jié)合。 缺點(diǎn)：語義相對(duì)于類圖來說更弱一些，同時(shí)對(duì)面向?qū)ο箝_發(fā)的指導(dǎo)作用相對(duì)差一些。,57,3E/R圖應(yīng)用基礎(chǔ),(1) 數(shù)據(jù)建模過程,58,(1) 數(shù)據(jù)建模過程,概念模型VS邏輯模型 概念模型和邏輯模型有什么區(qū)別呢?它們實(shí)際上是對(duì)“需求視圖”與“開發(fā)視圖”的區(qū)分。 換句話說，概念模型是需求人員的視圖，等價(jià)于現(xiàn)在出鏡率很高的領(lǐng)域模型； 而邏輯模型是開發(fā)人員(包括設(shè)計(jì)人員)的視圖，它約等于面向?qū)ο蠓治雠c設(shè)計(jì)方法中提到的“分析模型”。,59,概念模型VS邏輯模型具體區(qū)別： 完整性：邏輯模型在完整性上要比概念模型更勝一籌，通過在需求細(xì)化、設(shè)計(jì)的階段會(huì)對(duì)類的屬性進(jìn)行細(xì)化，會(huì)補(bǔ)充一些新的類。 加工方式：

25、概念模型的原則是忠于問題域，而邏輯模型則會(huì)從實(shí)現(xiàn)的便利性和需要的角度 進(jìn)行細(xì)化，具體來說可能會(huì)對(duì)一些類進(jìn)行分拆、合并。 邏輯模型VS物理模型區(qū)別 實(shí)際上是對(duì)“開發(fā)視圖”與“數(shù)據(jù)庫視圖”的區(qū)分，換句話說，物理模型就是DBA的視圖。,60,6.2.3 角色與使用場(chǎng)景分析,在傳統(tǒng)的結(jié)構(gòu)化分析與設(shè)計(jì)方法中，整個(gè)分析視角是站在解決方案域的，很容易產(chǎn)生對(duì)問題域分析不足的結(jié)果。 以用例技術(shù)(屬于面向?qū)ο蠓治雠c設(shè)計(jì)方法的范疇)為代表的現(xiàn)代需求分析方法則更側(cè)重于“從用戶的角度，將系統(tǒng)當(dāng)做一個(gè)黑盒子”的視角。 用例分析技術(shù)的關(guān)鍵是“發(fā)現(xiàn)使用系統(tǒng)的角色(參與者)，了解并梳理這些角色將如何使用系統(tǒng)(場(chǎng)景)”，從而更好

26、地完成“人”的視角的需求梳理。,61,1.用例分析概述,用例圖是用例分析的全部內(nèi)容？錯(cuò)！ 用例分析 包括：用例圖和用例描述。用例圖是目錄，用例描述是封裝所有需求的形式 。,用例分析的組成,62,6.2.3 角色與使用場(chǎng)景分析,2參與者與用例 (1)參與者:參與者是在系統(tǒng)之外，透過系統(tǒng)邊界與系統(tǒng)進(jìn)行有意義交互的任何事物。,63,(2)用例,根據(jù)RUP的定義：用例實(shí)例(場(chǎng)景)是在系統(tǒng)中執(zhí)行的一系列動(dòng)作，這些動(dòng)作將生成特定執(zhí)行者可見的價(jià)值結(jié)果。一個(gè)用例定義一組用例實(shí)例。 用例場(chǎng)景是有步驟的(執(zhí)行了一系列動(dòng)作)：也就是說，它是一個(gè)由一系列業(yè)務(wù)步驟組成的業(yè)務(wù)活動(dòng)。 用例場(chǎng)景是有目標(biāo)的(可見的價(jià)值結(jié)果)：

27、也就是說，它能夠?yàn)閰⑴c者帶來有意義的結(jié)果，例如“填寫搜索條件”顯然就是對(duì)參與者而言沒有意義的，就不是一個(gè)合適的用例。 例是對(duì)一組用例實(shí)例(場(chǎng)景)的抽象，也就是說，用例是有路徑(基本事件流、擴(kuò)展事件流、子事件流等)的。例如我們?cè)趶腗上取款時(shí)，可能會(huì)遇到很多不同的場(chǎng)景： 正常取到錢、卡里錢不夠、密碼忘了、機(jī)器里沒有足夠的錢、卡被吞了等；而這些都可以概括為一個(gè)名為“取款”的用例。,64,(2)用例,從某種意義上說，用例和具體場(chǎng)景(用例實(shí)例)之間的關(guān)系和類與對(duì)象之間的關(guān)系是類似的。 一個(gè)場(chǎng)景是一個(gè)具體的行為，一個(gè)用例是對(duì)一類相關(guān)行為的抽象。,65,3用例圖,用例圖的構(gòu)成，以及用例與用例之間的關(guān)系、參與

28、者與用例之間的關(guān)系、參與者與參與者的關(guān)系,66,3用例圖,(1)系統(tǒng)邊界 (2)參與者與用例的關(guān)系 一個(gè)參與者表示用例的使用者在與這些用例進(jìn)行交互時(shí)所扮演的角色。 (3)用例之間的關(guān)系 包含、擴(kuò)展和泛化 (4)參與者之間的關(guān)系 參與者之間的關(guān)系只有一種，那就是泛化。,67,用例之間的關(guān)系,包含關(guān)系 在UML中，包含關(guān)系用構(gòu)造型include表示(箭頭方向是從基用例到被包含用例)，它是指基用例(base use case)在它內(nèi)部說明的某一個(gè)位置上顯式地合并了另一個(gè)用例的行為。 擴(kuò)展關(guān)系 在UML中，擴(kuò)展關(guān)系用構(gòu)造型extend表示(注意箭頭方向是從擴(kuò)展用例到基用例)，它表示基用例在由擴(kuò)展用例間

29、接說明的一個(gè)位置上，隱式地合并了另一個(gè)用例的行為。,68,泛化關(guān)系 而用例之間的泛化則表示子用例繼承了父用例的行為和含義；子用例還可以增加或覆蓋父用例的行為；子用例可以出現(xiàn)在父用例出現(xiàn)的任何位置。,69,70,(4)參與者之間的關(guān)系,參與者之間的關(guān)系只有一種，那就是泛化。,71,小結(jié),72,4用例的來源,自頂向下導(dǎo)出法 自底向上合并法,73,4用例的來源- (1)自頂向下導(dǎo)出法,自頂向下導(dǎo)出法就是從流程圖(流程圖是通過將系統(tǒng)分解成主題域，再從主題域中標(biāo)識(shí)出業(yè)務(wù)事件，然后為業(yè)務(wù)事件繪制出流程圖)中派生出用例圖。有了針對(duì)各個(gè)業(yè)務(wù)事件處理過程的流程圖，我們就可以從中導(dǎo)出相應(yīng)的用例。 崗位信息 -參與

30、者的候選者 業(yè)務(wù)活動(dòng)-用例的候選者,74,4用例的來源- (1)自頂向下導(dǎo)出法,針對(duì)每張流程圖進(jìn)行分析之后，就可以得到一組用例圖片段，然后將它們疊加在一起，就可以抽象出系統(tǒng)的用例模型。 如圖681所示的是某稅務(wù)效能管理系統(tǒng)中針對(duì)“業(yè)務(wù)申請(qǐng)”流程所繪制的一張跨職責(zé)流程圖，下面就以它為例，說明如何從流程圖中派生出用例圖。,75,76,利用流程圖， “邊界確定”、“角色確定”，以得出表示系統(tǒng)邊界的用例圖。 邊界確定(去除非End User的職責(zé)帶區(qū)) 首先要排除掉不直接使用系統(tǒng)的崗位，因?yàn)樗鼈儾皇窍到y(tǒng)要涉及的范疇。 確定角色(對(duì)剩下的職責(zé)帶區(qū)進(jìn)行角色化) 對(duì)于職責(zé)帶區(qū)“涉稅窗口” 。 對(duì)于職責(zé)帶區(qū)“

31、局內(nèi)業(yè)務(wù)科室” 。 確定用例 用例則是從職責(zé)帶區(qū)中的業(yè)務(wù)活動(dòng)派生出來的。分析過程見表6-9 ，6-10,77,對(duì)于活動(dòng)，主要是判斷它是否屬于系統(tǒng)范疇之內(nèi)； 對(duì)于判斷，則要分析它是屬于某個(gè)活動(dòng)還是一個(gè)獨(dú)立的活動(dòng)。,78,4用例的來源- (1)自頂向下導(dǎo)出法,繪制用例圖,79,4用例的來源-(2)自底向上的合并法,步驟 收集原始需求 當(dāng)我們獲得這樣的原始需求列表之后，就可以開始通過合并的方法來導(dǎo)出用例。當(dāng)然，我們首先需要確定有哪些參與者。 確定參與者 開發(fā)人員：對(duì)任務(wù)進(jìn)行操作和時(shí)間記錄； 項(xiàng)目經(jīng)理：對(duì)項(xiàng)目的任務(wù)進(jìn)行分配，了解項(xiàng)目內(nèi)產(chǎn)能； 研發(fā)經(jīng)理、管理層：確定項(xiàng)目及進(jìn)行產(chǎn)能統(tǒng)計(jì)工作。,80,4用例

32、的來源-(2)自底向上的合并法,合并用例 將“原始需求”按參與者分組，然后再合并或分解為相應(yīng)的用例 。 繪制用例圖 ,81,82,83,84,5用例分析技術(shù)應(yīng)用要點(diǎn),(1)用例真的有粒度嗎 業(yè)務(wù)價(jià)值判斷是關(guān)鍵 被包含用例、擴(kuò)展用例 技術(shù)性用例的引入 “用例粒度與系統(tǒng)復(fù) 雜度相關(guān)”的觀點(diǎn)是錯(cuò)誤的 影響用例大小的是業(yè)務(wù)流程，是工作任務(wù)的分工 CRUD的價(jià)值被過于放大了 CRUD是指在做計(jì)算處理時(shí)的增加(Create)、查詢(Retrieve)（重新得到數(shù)據(jù)）、更新(Update)和刪除(Delete) 用例合并成“管理* * ”,CRUD原則對(duì)于“系統(tǒng)創(chuàng)造的東西”才適用，例如管理系統(tǒng)用戶、管理數(shù)據(jù)

33、字典、管理權(quán)限、管理購物車之類的東西就適用于該原則。,85,5用例分析技術(shù)應(yīng)用要點(diǎn),(2)用業(yè)務(wù)動(dòng)詞命名用例十分重要 某開發(fā)團(tuán)隊(duì)在開發(fā)銀行信用卡管理系統(tǒng)時(shí)，整理了一些用例，其中包括：創(chuàng)建客戶、更新客戶、刪除客戶。,86,5用例分析技術(shù)應(yīng)用要點(diǎn),(3)采用先事后人的方式分析是要點(diǎn) 應(yīng)該將人(角色、參與者)和事(場(chǎng)景、用例)分開考慮； 在確定它們之間關(guān)聯(lián)時(shí)，要先事后人地思考。 在確定了參與者之后，再抽取出“事”(也就是用例)，然后完成它們之間的連接，就可以很輕松地獲得更合理的結(jié)果了。,87,案例,在開發(fā)一套醫(yī)院管理系統(tǒng)時(shí)，分析人員了解到如下所示的需求： 在藥房中，有3個(gè)主參與者：接待員、藥房技師和

34、藥劑師。其中任何一個(gè)參與者都可能接待客戶，接收處方。藥房技師和藥劑師都可以按照處方抓藥，但只有藥劑師有權(quán)審核處方并在處方中簽字，而藥房技師是協(xié)助藥劑師的。 找出參與者：接待員、藥房技師和藥劑師 抽取出“事”（用例）：收處方、配藥、審核 (業(yè)務(wù)活動(dòng) ) 找出關(guān)系：,88,89,62. 4 周期一的產(chǎn)物,體檢醫(yī)院管理系統(tǒng) “客服管理子系統(tǒng)”、“體檢業(yè)務(wù)子系統(tǒng)”和“物資管理子系統(tǒng)”三個(gè)主題域。以“體檢業(yè)務(wù)子系統(tǒng) ”為例。 1工作任務(wù)說明 在需求分析的第一階段，核心任務(wù)就是結(jié)合業(yè)務(wù)流程、報(bào)表的需求，梳理出結(jié)構(gòu)框架(領(lǐng)域模型)和行為脈絡(luò)(流程圖-用例模型)，為第二階段的需求分析工作建立基礎(chǔ)；指出方向。

35、而具體來說，就是從上一階段標(biāo)識(shí)出來的業(yè)務(wù)事件(業(yè)務(wù)流程的起點(diǎn))和報(bào)表列表開始，展開對(duì)中層管理人員的訪談與調(diào)研，而范圍就是“體檢業(yè)務(wù)子系統(tǒng)”所對(duì)應(yīng)的服務(wù)中心、體檢科室和綜合科三個(gè)部門。然后再根據(jù)訪談的結(jié)果完成事、物、人的分析，最后在此基礎(chǔ)上抽象出該主題域的領(lǐng)域模型和用例模型。,90,2業(yè)務(wù)事件分析 標(biāo)識(shí)出了體檢者申請(qǐng)?bào)w檢、體檢者中途改單、財(cái)務(wù)部門提交團(tuán)隊(duì)繳費(fèi)情況、客服中心查詢體檢情況、維護(hù)人員管理體檢項(xiàng)和系統(tǒng)通知用戶取報(bào)告6個(gè)業(yè)務(wù)事件 以 “體檢者申請(qǐng)?bào)w檢”業(yè)務(wù)事件為例 進(jìn)行 業(yè)務(wù) 流程分析 、業(yè)務(wù)實(shí)體分析、角色使用場(chǎng)景分析,91,體檢者申請(qǐng)?bào)w檢-業(yè)務(wù)流程,訪談過程中，用戶代表描述的信息： 當(dāng)體

36、檢者要體檢時(shí)，首先將到服務(wù)中心辦理。如果已經(jīng)預(yù)約，則告訴服務(wù)人員其預(yù)約號(hào)或姓名；如果沒有預(yù)約則填寫體檢申請(qǐng)表，選擇體檢項(xiàng)目或體檢套餐(可以自由組合體檢項(xiàng)目和體檢套餐)。服務(wù)人員將根據(jù)預(yù)約單或體檢申請(qǐng)表的內(nèi)容生成系統(tǒng)中的體檢單，并打印出來。 體檢者拿著體檢單到收費(fèi)窗口交費(fèi)，收費(fèi)人員根據(jù)體檢單中的體檢項(xiàng)或體檢套餐對(duì)應(yīng)的費(fèi)用項(xiàng)計(jì)算總費(fèi)用，生成相應(yīng)的賬單，收完費(fèi)用后在體檢單上蓋上“收費(fèi)已迄”的圖章；如果公司已經(jīng)付過相應(yīng)費(fèi)用，則直接蓋上“收費(fèi)已迄”圖章。 體檢者拿著體檢單到各體檢科室進(jìn)行體檢，體檢醫(yī)生體檢完后在體檢單上注明已體檢，并在體檢完成后將該體檢項(xiàng)的體檢結(jié)果記錄在電腦中。 當(dāng)所有的體檢項(xiàng)都體檢完之

37、后，綜合科醫(yī)生將根據(jù)體檢結(jié)果填寫體檢報(bào)告。 當(dāng)體檢報(bào)告生成完畢后，服務(wù)人員就可以將其返還給客戶?？蛻艨梢宰孕蓄I(lǐng)取，可由公司代表統(tǒng)一領(lǐng)取，也可以由客服中心人員代為領(lǐng)取。,92,(1)體檢者申請(qǐng)?bào)w檢 業(yè)務(wù)流程分析,93,業(yè)務(wù)實(shí)體分析 業(yè)務(wù)實(shí)體分析的關(guān)鍵是理清問題域中的關(guān)鍵術(shù)語之間的關(guān)系， 找出候選類，及其關(guān)系，繪制類圖,94,角色使用場(chǎng)景分析 。 最后我們還將研究項(xiàng)目的邊界，完成流程圖到用例圖的轉(zhuǎn)換，完成系統(tǒng)的角色和使用場(chǎng)景分析。,95,將本業(yè)務(wù)流程所涉及的所有業(yè)務(wù)活動(dòng)以如圖6-91所示的用例圖表示出來,96,3報(bào)表分析 對(duì)于報(bào)表而言，分析工作可以分成why(目標(biāo))、what(內(nèi)容)與How(展現(xiàn)

38、形式)三個(gè)層次 以“體檢業(yè)務(wù)周期統(tǒng)計(jì)報(bào)表”為例 (1)why:對(duì)于報(bào)表而言，Why要解決的問題包括：部門職位、目的、相關(guān)場(chǎng)景與查詢頻率等方面的內(nèi)容。,97,(2)what(內(nèi)容): 對(duì)于每一類報(bào)表，我們還需要確定與它相關(guān)的業(yè)務(wù)實(shí)體(用類圖來表示)、主要的數(shù)據(jù)項(xiàng)、數(shù)據(jù)項(xiàng)的計(jì)算方法，同時(shí)還要確定有多少具體的報(bào)表。 相關(guān)業(yè)務(wù)實(shí)體分析 報(bào)表項(xiàng)分析 數(shù)據(jù)項(xiàng)及計(jì)算方法分析,98,4抽象與整理,(1)抽象用例模型 (2)抽象類模型,5填充需求規(guī)格說明,通過以上分析，就可以完成結(jié)構(gòu)框架和行為脈絡(luò)的填充，同時(shí)將其填充到軟件需求規(guī)格說明書中 。 (1)Word文檔組織示例 (2) Rose組織示例,99,第6章

39、需求分析與建模最佳實(shí)踐,6.1 需求分析與建模的要點(diǎn)與誤區(qū)分析 6.2 周期一:理清框架與脈絡(luò) 6.3 周期二：確定需求細(xì)節(jié) 6.4 其他需求分析,100,6.3 周期二：確定需求細(xì)節(jié),6.3.1 確定行為需求的細(xì)節(jié) 6.3.2 確定結(jié)構(gòu)需求的細(xì)節(jié) 6.3.3 周期二的產(chǎn)物,101,這個(gè)階段的任務(wù)是對(duì)用例模型、領(lǐng)域模型標(biāo)識(shí)出用例、領(lǐng)域類的細(xì)節(jié)進(jìn)行填充。 對(duì)于組織行為需求的用例，我們要填充用例的事件流、相關(guān)需求與功能點(diǎn)、界面原型，以及特定于該用例的規(guī)則與約束； 對(duì)于組織數(shù)據(jù)(結(jié)構(gòu))需求的領(lǐng)域類，我們要填充它的字段與格式，具體包括： 字段屬性信息：也就是每個(gè)領(lǐng)域類所包含的成員屬性，細(xì)化其構(gòu)成； 字

40、段格式與規(guī)則：也就是每個(gè)字段詳細(xì)的格式(諸如字符型、日期型等類型，以及長度可選值等內(nèi)容)、組成規(guī)則(諸如由多少個(gè)字符、多少個(gè)數(shù)字組成等)； 計(jì)算規(guī)則：對(duì)于一些非直接輸入的派生屬性，通過數(shù)據(jù)表達(dá)式的方式來描述； 結(jié)構(gòu)規(guī)則：對(duì)于數(shù)據(jù)的組成、格式進(jìn)行描述。,102,6.3.1 確定行為需求的細(xì)節(jié),1用例的靈活應(yīng)用 2用例描述模板 3事件流分析 4相關(guān)需求整理 5界面原型 6規(guī)則與約束,103,6. 3. 1 確定行為需求的細(xì)節(jié),1用例的靈活應(yīng)用 根據(jù)行為需求的特點(diǎn)，可以將其分成“業(yè)務(wù)功能、報(bào)表功能、接口、技術(shù)支撐” 4種類型。 統(tǒng)一封裝成用例，但在具體細(xì)節(jié)描述方面，可以對(duì)其進(jìn)行靈活處理，具體的方法如

41、表617所示,104,6. 3. 1 確定行為需求的細(xì)節(jié),2用例描述模板 而針對(duì)業(yè)務(wù)功能類的用例來說，其需要整理的內(nèi)容主要包括事件流、相關(guān)需求與功能點(diǎn)、界面原型、規(guī)則與約束4個(gè)方面，描述的方法可以采用通用的用例描述模板來組織。 相關(guān)的用例描述模板有不少，最常用的包括RUP所提供的經(jīng)典模型和編寫有效用例作者所提供的模板。,105,106,6. 3. 1 確定行為需求的細(xì)節(jié),3事件流分析 一個(gè)用例通常是一組事件流所構(gòu)成的。整個(gè)事件流模型包括：前、后置條件、基本事件流和擴(kuò)展事件流。 (1)前、后置條件 所謂前置條件是指在用例啟動(dòng)時(shí)，參與者(Actor)與系統(tǒng)應(yīng)置于什么狀態(tài)。這個(gè)狀態(tài)應(yīng)該是系統(tǒng)能夠檢測(cè)

42、到的，在用例啟動(dòng)前能夠檢測(cè)到的，而且還應(yīng)該是有意義的。 所謂后置條件是指在用例結(jié)束時(shí)，系統(tǒng)應(yīng)置于什么狀態(tài) ，這個(gè)狀態(tài)應(yīng)該是系統(tǒng)能夠檢測(cè)到的，在用例結(jié)束前能夠檢測(cè)到的，而且也應(yīng)該是有意義的。,107,6. 3. 1 確定行為需求的細(xì)節(jié),3事件流分析 (2)事件流的類型 對(duì)于用例而言，最常見的事件流類型包括3種: 基本事件流：是對(duì)用例中常規(guī)、預(yù)期路徑的描述。 擴(kuò)展事件流：也稱為備選事件流、可選事件流；主要包括可選分支(用戶的不同選擇)、異常情況等情況。 子事件流：用來對(duì)事件流中多次重復(fù)的部分進(jìn)行概括，以便在用例描述中復(fù)用；通常會(huì)對(duì)其進(jìn)行命名。 (3)業(yè)務(wù)用例與系統(tǒng)用例 業(yè)務(wù)用例描述的是所有的業(yè)務(wù)步

43、驟，而系統(tǒng)用例則只描述與系統(tǒng)相關(guān)的業(yè)務(wù)步驟。,108,案例-機(jī)場(chǎng)Checkin場(chǎng)景描述,我招呼隊(duì)列中的下一名顧客。當(dāng)他走到我的桌子前時(shí)，我要求他出示機(jī)票。如果乘客使用電子機(jī)票，我需要訂票記錄標(biāo)識(shí)符。大多數(shù)乘客不會(huì)記住它，所以我會(huì)問他們的姓名和航班。大多數(shù)人不知道他們的航班號(hào)，所以我通常會(huì)問他們的目的地。他們肯定知道的。 我確信乘客和航班都是正確的。給錯(cuò)座位或者將乘客送到錯(cuò)誤的目的地都會(huì)是很尷尬的事情。無論如何，我會(huì)設(shè)法在計(jì)算機(jī)中定位乘客的航班記錄。如果他沒有將護(hù)照給我，我會(huì)向他要。我會(huì)查看護(hù)照的照片是否與乘客相似，并檢查護(hù)照是否仍然有效。 如果記票記錄沒有顯示出?？途幪?hào)，我會(huì)問乘客是否參加了我

44、們的里程計(jì)劃。要么他給我?？涂ǎ次覇査欠裨敢饧尤?，并給他表格。我可以為航班記錄提供臨時(shí)的?？途幪?hào)，這樣乘客就可以將這次行程計(jì)入總里程。 如果計(jì)算機(jī)還沒有指定座位，我會(huì)找一個(gè)。這通常意味著我會(huì)問顧客靠窗還是靠走道，或者如果座位基本滿了，我會(huì)告訴他還有哪些座位。當(dāng)然如果計(jì)算機(jī)分配了一個(gè)座位，我總是會(huì)問他是否滿意。我們確定了座位后，會(huì)在計(jì)算機(jī)上確認(rèn)。此時(shí)我可以打印登機(jī)牌，但是通常我會(huì)先處理行李。 我會(huì)問乘客要托運(yùn)多少件行李，同時(shí)令確認(rèn)他沒有超出攜帶行李的限制。難以相信有些人總是希望將什么東西都帶進(jìn)空間有限的機(jī)艙中。我會(huì)對(duì)行李提一些安全性問題，并得到乘客的回答。我舍打印出行李標(biāo)簽并將它們安全地貼

45、在行李上，然后我合將行李送到傳送帶上，完成行李托運(yùn)工作。 接下來我會(huì)打印登機(jī)牌。這意味著我完成了所有與計(jì)算機(jī)相關(guān)的事情。但還有一件事要做：我要確保每什事都與乘客的理解一致。我會(huì)從登機(jī)牌上讀出他的目的地、航班的時(shí)間、何時(shí)如何登機(jī)，還會(huì)說明他托運(yùn)了多少件行李，并確認(rèn)行李的目的地與乘客的目的一致，然后將登機(jī)牌給乘客，并祝他旅途愉快。,109,6. 3. 1 確定行為需求的細(xì)節(jié),4相關(guān)需求整理 (1)用戶原始需求 將需求捕獲階段獲得的用戶原始需求(通常每個(gè)原始需求是以一句話)整理到相應(yīng)的用例中是一種很好的實(shí)踐，它可以更好地建立用戶原始需求和軟件需求(用例)之間的映射。 (2)相關(guān)功能點(diǎn) 在需求規(guī)格說明

46、書中除了可以將用戶原始需求歸類整理進(jìn)來，作為開發(fā)時(shí)的重要參考依據(jù)之外，有時(shí)可能還會(huì)涉及一些無法有效地表述在事件流中的小功能點(diǎn)。,110,6. 3. 1 確定行為需求的細(xì)節(jié),5界面原型 (1) 要點(diǎn) (2)交互不要忽略,111,5界面原型-(3)別讓界面掩蓋本質(zhì),112,6. 3. 1 確定行為需求的細(xì)節(jié),6規(guī)則與約束 規(guī)則是在實(shí)現(xiàn)時(shí)應(yīng)該考慮的東西，而約束則是對(duì)技術(shù)手段選擇起到限制作用的各種條件。 (1)規(guī)則的類型 從需求的角度來看，涉及的規(guī)則大致可以分為：行為(或稱為功能、業(yè)務(wù))規(guī)則、結(jié)構(gòu)(或稱為數(shù)據(jù))規(guī)則、界面規(guī)則三類。 行為規(guī)則：或稱為功能規(guī)則、業(yè)務(wù)規(guī)則，它是指和業(yè)務(wù)邏輯、業(yè)務(wù)流程相關(guān)的規(guī)

47、則。 結(jié)構(gòu)規(guī)則：或稱為數(shù)據(jù)規(guī)則，它是指和業(yè)務(wù)實(shí)體、屬性、派生屬性相關(guān)的規(guī)則。 .界面規(guī)則：它是指和用戶界面相關(guān)的規(guī)則。,113,6. 3. 1 確定行為需求的細(xì)節(jié),6規(guī)則與約束 (2)用例級(jí)的約束 通常來說約束都是全局需求，但也有一小部分是局部的，這類約束通常會(huì)放在具體的用例中。具體來說，它主要可以分成以下幾種類型： 性能指標(biāo)等非功能要求 軟、硬件環(huán)境限制 技術(shù)選擇限制 用戶特點(diǎn)及環(huán)境限制,114,632 確定結(jié)構(gòu)需求的細(xì)節(jié),行為需求隱藏在“主題域-業(yè)務(wù)事件-業(yè)務(wù)活動(dòng)(用例)-業(yè)務(wù)步驟”的分解結(jié)構(gòu)中，也就是歸納在用例模型中； 結(jié)構(gòu)需求應(yīng)該歸納在自底向上生成的領(lǐng)域模型中。,115,632 確定結(jié)

48、構(gòu)需求的細(xì)節(jié),1基本內(nèi)容 (1)領(lǐng)域模型的組織 從領(lǐng)域模型的組織角度說，通常會(huì)首先按照主題域進(jìn)行第一次分解，一個(gè)主題域?qū)?yīng)一個(gè)領(lǐng)域模型，然后根據(jù)需要可以將各個(gè)主題域中共性的領(lǐng)域類抽取出來，形成全局公共的領(lǐng)域類模型。 而對(duì)于每個(gè)主題域內(nèi)的領(lǐng)域模型(包括全局公共的領(lǐng)域模型)而言，涉及的領(lǐng)域類可能還是很多，那我們可以根據(jù)其邏輯關(guān)系劃分成不同的部分，通常用包來表示；每個(gè)包中就是一個(gè)邏輯相關(guān)的領(lǐng)域類圖片段。 接著，我們可以對(duì)每張領(lǐng)域類圖片段進(jìn)行簡要的概述，羅列針對(duì)所有領(lǐng)域類的共性結(jié)構(gòu)規(guī)則，然后再分而治之地進(jìn)行描述,116,632 確定結(jié)構(gòu)需求的細(xì)節(jié),接下來，我們就可以對(duì)每個(gè)領(lǐng)域類做進(jìn)一步描述了。通?？梢?/p>

49、從“數(shù)據(jù)窗口分析”、“數(shù)據(jù)組成與格式”、“派生數(shù)據(jù)的計(jì)算方法”三個(gè)角度進(jìn)行描述。 (2)數(shù)據(jù)窗口分析 每個(gè)業(yè)務(wù)事件就是一個(gè)數(shù)據(jù)窗口； 根據(jù)業(yè)務(wù)事件所對(duì)應(yīng)的流程圖中標(biāo)識(shí)的文檔，逐一分析，填充中相應(yīng)的字段構(gòu)成，然后再抽取出共性的部分。,117,632 確定結(jié)構(gòu)需求的細(xì)節(jié),(3)數(shù)據(jù)組成與格式 . 數(shù)據(jù)類型 . 長度、精度信息 . 組成格式：也就是具體的構(gòu)成規(guī)則，例如編號(hào)由2位字母、6位數(shù)字和一個(gè)可選的x組成。 (4)派生數(shù)據(jù)的計(jì)算方法 決策表、決策樹 p274,118,633 周期二的產(chǎn)物,1工作任務(wù)說明 2填充用例描述 3填充領(lǐng)域類細(xì)節(jié) 4填充需求規(guī)格說明,119,633 周期二的產(chǎn)物,1工作任

50、務(wù)說明 在需求分析的第一階段(周期一)，完成了結(jié)構(gòu)框架(領(lǐng)域模型)和行為脈絡(luò)(流程圖十用例模型)的梳理; 在第二階段，工作任務(wù)就是填充需求的細(xì)節(jié)，具體來說就是根據(jù)前面說明的過程與內(nèi)容來填充用例、填充領(lǐng)域類。,120,633 周期二的產(chǎn)物,1工作任務(wù)說明 2填充用例描述 3填充領(lǐng)域類細(xì)節(jié) 4填充需求規(guī)格說明,121,633 周期二的產(chǎn)物,2填充用例描述 將用例分成了業(yè)務(wù)功能類、報(bào)表類、接口類和技術(shù)類4種。 一個(gè)業(yè)務(wù)功能類(Actor服務(wù)人員的“開單”用例)、一個(gè)報(bào)表類(體檢業(yè)務(wù)周期統(tǒng)計(jì)報(bào)表)的用例來說明填充用例描述的工作有哪些，應(yīng)該生成什么產(chǎn)物。 對(duì)于接口類用例的示例請(qǐng)參見“641接口需求”小節(jié)

51、，對(duì)于技術(shù)類用例的說明請(qǐng)參見“642非功能需求的追蹤”小節(jié)。,122,633 周期二的產(chǎn)物,(1)開單用例分析 用例概述 通常在用例模型創(chuàng)建的同時(shí)，我們會(huì)對(duì)其做概要性描述；內(nèi)容主要包括用例名稱、編號(hào)、參與者、用例概述、相關(guān)Stakeholder等幾個(gè)部分。 事件流分析 對(duì)該用例的前、后置條件進(jìn)行分析。 接下來，我們可以對(duì)用例的事件流進(jìn)行分析。 相關(guān)需求 相關(guān)需求包括兩個(gè)方面：一個(gè)是用戶的原始需求；另一個(gè)是需求人員發(fā)現(xiàn)難以歸納到用例事件流中的功能點(diǎn)。,123,633 周期二的產(chǎn)物,(1)開單用例分析 用戶界面原型 首先應(yīng)該考慮用戶界面原型中的交互過程。 為每個(gè)窗口進(jìn)一步創(chuàng)建更加細(xì)節(jié)的界面說明，其內(nèi)容不僅包括界面上的元素，還應(yīng)該有一些相應(yīng)的說明。 規(guī)則與約束 對(duì)于每個(gè)用例而言，規(guī)則與約束是僅針對(duì)該用例