軟件工程：理論、技術(shù)及實踐 課件 第4、5章 理解需求、需求分析

第4章

理解需求本章學(xué)習(xí)目標(biāo)1.了解有關(guān)需求的基本知識。2.掌握需求工程的主要活動及它們之間的關(guān)系。3.掌握需求獲取主要方法。4.應(yīng)用用例和場景對需求建模。5.應(yīng)用用戶故事地圖建立項目需求。

需求工程1軟件需求獲取2用例和場景3用戶故事地圖40理解需求Brooks曾描述“構(gòu)建一個軟件系統(tǒng)最困難的部分是確定構(gòu)建什么，其他部分工作不會像這部分工作一樣，在出錯之后會如此嚴(yán)重地影響隨后實現(xiàn)的系統(tǒng)，并且以后修補竟會如此的困難?！?.1需求工程需求工程的介紹對軟件工程師來說，理解項目的需求是什么是他們所面臨的最困難的工作之一。很多時候客戶也不確切知道自己需要的是什么。他們能夠接受在軟件開發(fā)過程中需求的不斷變化：有些是由溝通引起的，有些是外部干預(yù)者強加的，還有一些是客戶隨著項目演進不斷提高對系統(tǒng)需求的認識所導(dǎo)致的。需求工程（RequirementsEngineering，簡稱RE）不能清晰地解決上述所有問題，但是項目總要有一個起始點，可以把需求工程理解為解決上述問題的一個較為可靠的途徑。4.1需求工程需求工程劃分為五個獨立的階段：（1）需求獲取階段需求獲取指通過與各利益相關(guān)者交流、觀察現(xiàn)有系統(tǒng)以及對任務(wù)進行探討，從而捕獲、導(dǎo)出和不斷修訂用戶的需求的過程。在需求獲取階段，可以確定的一些利益相關(guān)者有：最終用戶、軟件工程師、產(chǎn)品工程師、業(yè)務(wù)運行管理人員、產(chǎn)品管理人員、市場銷售人員、支持和維護工程師等。4.1需求工程需求工程劃分為五個獨立的階段：（1）需求獲取階段下列因素導(dǎo)致了導(dǎo)出需求的困難：①范圍：系統(tǒng)的邊界不清楚、或是客戶（用戶）說明中帶有不必要的技術(shù)細節(jié)，混淆而不是澄清系統(tǒng)的整體目標(biāo)。②理解：客戶（用戶）并不能完全確定需要什么。③易變：需求會隨著時間發(fā)生變化。在給定有限資源情況下，客戶或者用戶可能提出過高的要求，利益相關(guān)者也可能提出了相互沖突的需求，并強調(diào)他們各自要求的重要性。需求工程師必須通過協(xié)商過程來調(diào)節(jié)這些沖突。4.1需求工程需求工程劃分為五個獨立的階段：（2）需求分析階段需求分析是通過前面階段全面的需求獲取后，對需求進行的整理、規(guī)范和分析，用以說明軟件的功能、特征和信息等各個方面。該階段的任務(wù)主要集中于得到一個精確的需求模型。4.1需求工程需求工程劃分為五個獨立的階段：（3）需求定義階段需求定義是指在對所要開發(fā)的產(chǎn)品達成共識后，形成一份需求的一致性定義，也就是需求規(guī)格說明。如：IEEE的需求規(guī)格說明書模板。4.1需求工程需求工程劃分為五個獨立的階段：（4）需求確認階段需求確認主要是就需求定義和利益相關(guān)者進行溝通，并獲得利益相關(guān)者的認可。在需求確認階段需要做到以下幾點：①軟件需求規(guī)格說明正確描述了預(yù)期的滿足各方需求的系統(tǒng)能力和特征。②從系統(tǒng)需求、業(yè)務(wù)規(guī)則或其他來源中正確地推導(dǎo)出軟件需求。③需求是完整的、高質(zhì)量的。④需求的表述在所有地方都是一致的。⑤需求為繼續(xù)進行產(chǎn)品設(shè)計和構(gòu)造提供了充分的基礎(chǔ)。⑥可以預(yù)先設(shè)計一些需求確認檢查表來檢查每項需求是否是有用的。4.1需求工程需求工程劃分為五個獨立的階段：（5）需求跟蹤和變更控制階段需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)，建立與維護“需求——設(shè)計——編程——測試”等后續(xù)工作之間的一致性，確保所有工作成果符合用戶需求。4.2軟件需求獲取需求提取是發(fā)現(xiàn)用戶真實需要的過程，也稱需求捕獲。軟件需求提取可以分成兩個步驟：理解應(yīng)用領(lǐng)域和建立商業(yè)過程模型。例如：開發(fā)一個移動終端的實驗室監(jiān)管系統(tǒng)可以使用UML中的用例（UseCase）圖、用例描述、活動圖等來對業(yè)務(wù)過程建模。4.2.1需求獲取方式4.2軟件需求獲取軟件需求的獲取方式主要有以下幾種：1.直接與用戶訪談和組織會談2.用戶工作環(huán)境體驗和資料采集3.潛在用戶調(diào)查報告4.市場相關(guān)產(chǎn)品調(diào)研5.快速原型方法4.2軟件需求獲取我們對系統(tǒng)建立的初始理解可以開始于對項目所處應(yīng)用領(lǐng)域的了解。利用術(shù)語表完成對該領(lǐng)域中應(yīng)用技術(shù)詞匯的列表解釋。例如：建立一個智慧教室系統(tǒng)智慧教室（SmartClassroom）的研究始于歐洲。從2005年英國雷丁大學(xué)研究智慧教室的學(xué)生交互行為開始，針對智慧教室的研究正式進入大眾的視野。4.2.2應(yīng)用領(lǐng)域理解4.2軟件需求獲取智慧教室主要是指借助互聯(lián)網(wǎng)技術(shù)、智能技術(shù)等構(gòu)建起來的新型教室。智慧教室旨在為教學(xué)活動提供人性化、智能化的互動空間；通過物理空間與數(shù)字空間的結(jié)合，本地與遠程的結(jié)合，改善人與學(xué)習(xí)環(huán)境的關(guān)系，在學(xué)習(xí)空間實現(xiàn)人與環(huán)境的自然交互，促進個性化學(xué)習(xí)、開放式學(xué)習(xí)和泛在學(xué)習(xí)。該類新型教室通過各類智能裝備的輔助更好地呈現(xiàn)教學(xué)內(nèi)容、便利獲取多樣化學(xué)習(xí)資源、促進在課堂上展開多重交互，實現(xiàn)情境感知與環(huán)境管理功能的自動調(diào)節(jié)。4.2.2應(yīng)用領(lǐng)域理解4.2軟件需求獲取（1）提供圖像識別系統(tǒng)，可以實現(xiàn)人臉考勤、用戶行為分析、用戶情感分析等。（2）提供物聯(lián)設(shè)備系統(tǒng)，可以實時監(jiān)控教室溫度、濕度等環(huán)境變化，并自動做出調(diào)整；能夠自動控制教室設(shè)備。（3）提供互動交互系統(tǒng)，通過智能錄課將線下課堂與云課堂結(jié)合，支持云端回看，同時配有電子白板和電子書包等?，F(xiàn)有的智慧教室的主要功能有：4.2軟件需求獲取表4-1智慧教室實例初始術(shù)語表術(shù)語解釋考勤系統(tǒng)考勤系統(tǒng)是指一套管理出勤記錄等相關(guān)情況的管理系統(tǒng)人臉考勤通過教室攝像頭記錄識別人臉信息完成考勤用戶行為分析學(xué)生課堂情緒與行為的檢測，包括對學(xué)生考勤、情緒、低頭及交頭接耳行為等進行識別物聯(lián)教室實時監(jiān)控教室溫度、濕度等環(huán)境變化，并自動做出調(diào)整，能夠自動控制教室設(shè)備智能錄課自動錄制課程并上傳到云端供學(xué)生課后查看云課堂基于云計算技術(shù)的一種高效、便捷、實時互動的遠程教學(xué)課堂形式電子白板顯示上課內(nèi)容，保存板書供學(xué)生課后學(xué)習(xí)電子書包利用信息化設(shè)備進行教學(xué)的便攜式終端4.2軟件需求獲取圖4-1智慧教室系統(tǒng)網(wǎng)絡(luò)拓撲結(jié)構(gòu)4.2.3應(yīng)用實例需求獲取智慧教室管理系統(tǒng)人臉考勤業(yè)務(wù)主要流程：（1）生物信息采集用智能終端采集人臉照片，并上傳到后臺系統(tǒng)中，由教師確認照片為學(xué)生本人無誤后，交由后臺識別軟件識別生成人臉信息庫。4.2軟件需求獲取4.2.3應(yīng)用實例需求獲取（2）考勤學(xué)生在教室就坐后，由教師提醒學(xué)生抬頭，并向智慧教室終端發(fā)送簽到指令，啟動考勤服務(wù)。通過教室的攝像頭采集教室里的學(xué)生圖像，通過網(wǎng)絡(luò)發(fā)送給云端服務(wù)軟件進行識別，并將識別結(jié)果和人臉信息庫中的信息進行匹配比對，若相似度大于設(shè)定的某個閾值，則考勤成功，反之則考勤失敗，暫記作缺勤處理。在上課期間，考勤系統(tǒng)持續(xù)工作，抓拍學(xué)生人臉圖像進行比對，對缺勤記錄進行修正。下課前，由老師關(guān)閉考勤服務(wù)。（3）統(tǒng)計結(jié)果考勤后，統(tǒng)計應(yīng)到學(xué)生數(shù)和實到學(xué)生數(shù)，并將對接的教務(wù)系統(tǒng)中請假的學(xué)生作標(biāo)注，最終得到本次的考勤結(jié)果。4.2軟件需求獲取4.2.3應(yīng)用實例需求獲?。?）人臉考勤時的特殊情況①錄入：錄入時學(xué)生可能會誤操作上傳其他人臉的照片，所以需要教師確認照片是學(xué)生本人無誤后再交由后臺處理。②考勤：考勤時學(xué)生可能低著頭未被攝像頭采集到人臉信息，所以需要學(xué)生主動抬起頭，或者在上課期間，多次補充人臉信息采集。③統(tǒng)計：可能存在學(xué)生請假，但未在教務(wù)系統(tǒng)上申請的情況，所以要提供可以修改考勤結(jié)果的途徑。④可能還有其他的異常情況會產(chǎn)生，需要在多次溝通后逐步調(diào)整需求。用例圖描述的是參與者所理解的系統(tǒng)功能，幫助人們以一種可視化的方式理解系統(tǒng)的功能需求，講述了最終用戶如何在一個特定環(huán)境下和系統(tǒng)交互。用例圖有四個部分：用例（UseCase）、參與者（Actor）、系統(tǒng)邊界、關(guān)系。（1）用例是參與者可以感受到的系統(tǒng)服務(wù)或功能單元。（2）參與者是與系統(tǒng)交互的人或物，是在將要說明的功能和行為環(huán)境內(nèi)使用系統(tǒng)或產(chǎn)品的外部實體或角色。參與者可以是人、其他軟件系統(tǒng)、硬件設(shè)備或其他與系統(tǒng)進行交互的實體。（3）系統(tǒng)邊界指系統(tǒng)與系統(tǒng)之間的界限。把系統(tǒng)邊界以外的同系統(tǒng)相關(guān)聯(lián)的其他部分稱為系統(tǒng)環(huán)境。4.3用例和場景4.3.1UML用例和場景4.3用例和場景4.3.1UML用例和場景（4）在用例圖中表示的關(guān)系有四種：關(guān)聯(lián)、泛化、包含和擴展。①關(guān)聯(lián)關(guān)系圖4-2用例圖中的關(guān)聯(lián)關(guān)系②泛化關(guān)系圖4-3父用例和子用例的關(guān)系圖4-4參與者之間存在泛化關(guān)系4.3用例和場景4.3.1UML用例和場景（4）在用例圖中表示的關(guān)系有四種：關(guān)聯(lián)、泛化、包含和擴展。③包含關(guān)系圖4-5用例之間包含關(guān)系示意圖④擴展關(guān)系圖4-6用例之間擴展關(guān)系4.3用例和場景4.3.1UML用例和場景在用例圖中，場景通常被定義為特定用例的一個或多個實例，用以描述系統(tǒng)如何與外部參與者交互以實現(xiàn)特定目標(biāo)或功能。場景描述了參與者如何與系統(tǒng)交互，觸發(fā)特定用例，以及系統(tǒng)對這些觸發(fā)的響應(yīng)。用例和場景之間的區(qū)別在于用例提供了整個功能的一般描述，而場景是用例的特定實例，就如對象是類的一個實例。場景的定義應(yīng)簡潔明了，利益相關(guān)者通過場景可以更好地理解系統(tǒng)的功能和行為。通過建立特定場景可以進一步提取需求。4.3.2應(yīng)用實例業(yè)務(wù)模型業(yè)務(wù)模型是對商業(yè)過程的描述，可以通過訪談，結(jié)合調(diào)查問卷、檢查業(yè)務(wù)上使用的各種表格以及對用戶直接觀察等方法來獲取業(yè)務(wù)模型信息。4.3用例和場景4.3.2應(yīng)用實例業(yè)務(wù)模型（1）初始系統(tǒng)用例智慧教室的人臉考勤業(yè)務(wù)模型概述為：學(xué)生在智慧教室后端上傳學(xué)生人臉照片，并由教師審核通過后存入人臉信息庫。上課時，教師通過智慧教室終端發(fā)送考勤指令，教室攝像頭采集學(xué)生人臉信息，交由后臺處理并將識別結(jié)果和人臉信息庫中的信息進行匹配比對，若存在相似度大于閾值的人臉信息，則考勤成功；反之則考勤失敗，先計成缺課處理。將所有教室里的學(xué)生進行考勤后，統(tǒng)計應(yīng)到學(xué)生數(shù)和實到學(xué)生數(shù)，減去對接的教務(wù)系統(tǒng)中已請假的學(xué)生，最終生成本次的考勤結(jié)果，并記錄在數(shù)據(jù)庫中。4.3用例和場景4.3.2應(yīng)用實例業(yè)務(wù)模型圖4-7系統(tǒng)初始用例圖初始需求時，由于對一些具體的業(yè)務(wù)流程還不清楚，在用例描述中可以不記錄詳細的操作步驟。表4-2課堂管理用例描述用例名稱課堂管理用例描述對智慧教室上課時系統(tǒng)進行操作與管理參與者教師與學(xué)生4.3用例和場景4.3.2應(yīng)用實例業(yè)務(wù)模型表4-3課程管理用例描述用例名稱課程管理用例描述對課程信息進行管理，如添加、修改、刪除課程信息、課程信息發(fā)布、教學(xué)班維護等操作參與者教師4.3用例和場景圖4-7系統(tǒng)初始用例圖4.3.2應(yīng)用實例業(yè)務(wù)模型表4-4考勤管理用例描述用例名稱考勤管理用例描述對考勤情況進行管理，如添加、修改、刪除考勤記錄等操作參與者教師、學(xué)生4.3用例和場景圖4-7系統(tǒng)初始用例圖4.3.2應(yīng)用實例業(yè)務(wù)模型表4-5教室管理用例描述用例名稱教室管理用例描述對上課教室管理，如教室基本信息維護，教室申請等操作參與者教師、樓管4.3用例和場景圖4-7系統(tǒng)初始用例圖4.3.2應(yīng)用實例業(yè)務(wù)模型表4-6設(shè)備管理用例描述用例名稱設(shè)備管理用例描述對智慧教室的設(shè)備進行管理，如設(shè)備信息錄入，設(shè)備分配等操作參與者系統(tǒng)管理員4.3用例和場景圖4-7系統(tǒng)初始用例圖4.3.2應(yīng)用實例業(yè)務(wù)模型表4-7用戶管理用例描述用例名稱用戶管理用例描述對智慧教室系統(tǒng)的用戶進行管理，如添加教師、添加學(xué)生等操作參與者系統(tǒng)管理員4.3用例和場景圖4-7系統(tǒng)初始用例圖（2）用例迭代需求獲取是一個迭代的過程，隨著需求獲取工作的深入展開，應(yīng)逐步細化用例和用例描述。4.3用例和場景4.3用例和場景表4-8人臉考勤用例描述用例名稱人臉考勤用例描述系統(tǒng)對學(xué)生人臉信息進行獲取與驗證參與者教師基本路徑1.教師發(fā)出考勤指令（1）教師選擇課程的人臉考勤選項（2）發(fā)出考勤指令（3）相關(guān)設(shè)備開始工作2.收集學(xué)生人臉信息并識別（1）智慧教室攝像頭采集教室內(nèi)照片（2）攝像頭識別出學(xué)生人臉交給后臺處理（3）后臺第三方圖像處理軟件處理人臉照片（4）將處理的結(jié)果與已有的人臉信息庫比對（5）比對結(jié)果相似度大于90%為考勤成功（6）比對結(jié)果相似度小于90%為考勤失敗3.對已請假的學(xué)生做處理（1）調(diào)用考勤管理用例中已請假的學(xué)生信息（2）將請假的學(xué)生作請假處理4.生成考勤結(jié)果并儲存（1）將考勤成功、缺勤和請假的學(xué)生標(biāo)記（2）將標(biāo)記后的結(jié)果存入數(shù)據(jù)庫異常路徑1.學(xué)生在教室但考勤失敗，到教師機專用考勤攝像頭補錄入或者手動考勤2.學(xué)生已請假，但是未在教務(wù)系統(tǒng)申請圖4-8課堂管理用例圖4.3用例和場景表4-9AI視頻錄課用例描述用例名稱AI視頻錄課用例描述AI智能錄課，并上傳云端供學(xué)生課后復(fù)習(xí)參與者教師和學(xué)生基本路徑1.教師在智慧教室終端點擊上課按鈕2.系統(tǒng)提示開始上課3.系統(tǒng)自動錄制上課內(nèi)容4.將錄制的內(nèi)容整理后系統(tǒng)自動上傳到智慧教室云課堂5.學(xué)生在智慧教室云課堂查看課程內(nèi)容異常路徑1.未在規(guī)定時間內(nèi)上課2.未點擊上課按鈕圖4-8課堂管理用例圖4.3用例和場景表4-10智慧白板應(yīng)用用例描述用例名稱智慧白板應(yīng)用用例描述智慧白板記錄上課板書，并上傳云端供學(xué)生課后復(fù)習(xí)查看參與者教師與學(xué)生基本路徑1.教師在智慧教室終端點擊上課按鈕2.系統(tǒng)提示開始上課3.系統(tǒng)自動記錄白板內(nèi)容4.系統(tǒng)將記錄的內(nèi)容整理后自動上傳到智慧教室云課堂5.學(xué)生在智慧教室云課堂查看課程內(nèi)容異常路徑1.未在規(guī)定時間內(nèi)上課2.未點擊上課按鈕圖4-8課堂管理用例圖4.3用例和場景表4-11智能環(huán)境監(jiān)控用例描述用例名稱智能環(huán)境監(jiān)控用例描述智慧教室系統(tǒng)自動監(jiān)控教室溫濕度環(huán)境情況并做出調(diào)節(jié)參與者智慧教室系統(tǒng)基本路徑1.教師在智慧教室終端點擊上課按鈕2.系統(tǒng)提示開始上課3.教室系統(tǒng)智能環(huán)境監(jiān)控開始工作4.環(huán)境監(jiān)控系統(tǒng)記錄監(jiān)控數(shù)據(jù)5.若監(jiān)控數(shù)據(jù)發(fā)現(xiàn)異常，自動提醒設(shè)備做出調(diào)節(jié)異常路徑1.未在規(guī)定時間內(nèi)上課2.未點擊上課按鈕圖4-8課堂管理用例圖4.3用例和場景表4-12課程信息維護用例描述圖4-9課程管理用例圖用例名稱課程信息維護用例描述教師對課程信息進行管理參與者教師基本路徑1.在課程管理菜單中選擇課程信息管理選項2.選擇增加、刪除、修改、查詢課程信息操作3.輸入相關(guān)信息并確認課程主要信息：課程號、課程名稱、課程簡介、課時、學(xué)分4.系統(tǒng)將相關(guān)數(shù)據(jù)保存到數(shù)據(jù)庫中4.3用例和場景表4-13課程發(fā)布用例描述用例名稱課程發(fā)布用例描述教師發(fā)布課程參與者教師基本路徑1.在課程管理菜單中選擇要發(fā)布的課程選項2.選擇可以看到課程發(fā)布的對象3.單擊發(fā)布按鈕4.系統(tǒng)提示是否確認發(fā)布5.確認后，系統(tǒng)顯示發(fā)布成功圖4-9課程管理用例圖4.3用例和場景表4-14教學(xué)班維護用例描述用例名稱教學(xué)班維護用例描述教師對教學(xué)班進行管理參與者教師基本路徑1.在課程管理菜單中選擇教學(xué)班管理選項2.選擇增加、刪除、修改、查詢教學(xué)班操作3.輸入相關(guān)信息并確認教學(xué)班主要信息：教學(xué)班編號、教學(xué)班名稱、教學(xué)班簡介、人數(shù)、所屬學(xué)院、學(xué)生名單4.系統(tǒng)將相關(guān)數(shù)據(jù)保存到數(shù)據(jù)庫中圖4-9課程管理用例圖4.3用例和場景表4-15考勤結(jié)果修改用例描述圖4-10考勤管理用例圖用例名稱考勤結(jié)果修改用例描述教師修改錯誤的考勤結(jié)果參與者教師基本路徑1.在考勤管理菜單中選擇考勤結(jié)果修改選項2.輸入學(xué)生學(xué)號3.選擇考勤時間4.輸入正確的考勤結(jié)果5.單擊提交按鈕，系統(tǒng)顯示修改考勤結(jié)果成功4.3用例和場景表4-16考勤結(jié)果申訴用例描述用例名稱考勤結(jié)果申訴用例描述學(xué)生申訴錯誤的考勤結(jié)果參與者學(xué)生基本路徑1.在考勤管理菜單中選擇考勤結(jié)果申訴選項2.輸入學(xué)生學(xué)號3.選擇考勤時間4.輸入正確的考勤結(jié)果5.單擊申訴按鈕，系統(tǒng)顯示考勤結(jié)果申訴提交成功擴展路徑1.學(xué)生申訴不予通過圖4-10考勤管理用例圖4.3用例和場景表4-17請假申請用例描述用例名稱請假申請用例描述學(xué)生在智慧教室系統(tǒng)中提交請假申請參與者學(xué)生基本路徑1.在考勤管理菜單中選擇請假申請選項2.輸入學(xué)生學(xué)號3.選擇請假時間4.輸入請假原因5.單擊申請請假按鈕，系統(tǒng)顯示申請請假提交成功擴展路徑1.不在該課程請假時間范圍內(nèi)，請假失敗圖4-10考勤管理用例圖4.3用例和場景表4-18請假管理用例描述用例名稱請假管理用例描述教師在智慧教室系統(tǒng)中審批學(xué)生請假信息參與者教師基本路徑1.在考勤管理菜單中選擇請假管理選項2.選擇請假學(xué)生3.系統(tǒng)顯示請假原因和請假時間4.單擊同意按鈕，系統(tǒng)顯示該學(xué)生請假成功，或者單擊不同意按鈕，系統(tǒng)顯示該學(xué)生請假不成功圖4-10考勤管理用例圖4.3用例和場景表4-19教室信息管理用例描述圖4-11教室管理用例圖用例名稱教室信息管理用例描述樓管對教室信息進行管理參與者樓管基本路徑1.在教室管理菜單中選擇教室信息管理選項2.選擇增加、刪除、修改、查詢教室信息操作3.輸入相關(guān)信息并確認教室信息包括：教室編號、教室位置、教室類型、座位數(shù)量、教室用途4.系統(tǒng)將相關(guān)數(shù)據(jù)保存到數(shù)據(jù)庫中4.3用例和場景表4-20教室使用申請用例描述用例名稱教室使用申請用例描述樓管與教師對智慧教室使用申請進行管理參與者樓管與教師基本路徑1.教師在教室管理菜單中選擇使用申請選項2.選擇增加、刪除、修改、查詢操作3.教師輸入相關(guān)申請信息并提交申請管理信息包括：申請時間、教室編號、申請用途、申請人編號4.樓管對教室申請信息進行確認5.系統(tǒng)將相關(guān)數(shù)據(jù)保存到數(shù)據(jù)庫中圖4-11教室管理用例圖4.3用例和場景表4-21設(shè)備登記用例描述圖4-12設(shè)備管理詳細用例圖用例名稱設(shè)備登記用例描述系統(tǒng)管理員登記新設(shè)備參與者系統(tǒng)管理員基本路徑1.在設(shè)備管理菜單中選擇設(shè)備登記選項2.選擇需要登記的設(shè)備3.輸入相關(guān)登記信息并點擊登記登記信息包括：設(shè)備名稱、設(shè)備型號、生產(chǎn)廠商、產(chǎn)品序列號、登記的時間4.相關(guān)信息保存到數(shù)據(jù)庫中4.3用例和場景表4-22設(shè)備分配用例描述用例名稱設(shè)備分配用例描述系統(tǒng)管理員分配設(shè)備到智慧教室參與者系統(tǒng)管理員基本路徑1.在設(shè)備管理菜單中選擇設(shè)備分配選項2.選擇需要分配的設(shè)備3.選擇需要分配到的教室4.確認后點擊分配按鈕5.保存到數(shù)據(jù)庫中異常路徑1.設(shè)備無法分配圖4-12設(shè)備管理詳細用例圖4.3用例和場景表4-23用戶信息管理用例描述圖4-13用戶管理用例圖用例名稱用戶信息管理用例描述系統(tǒng)管理員管理用戶信息參與者系統(tǒng)管理員基本路徑1.在用戶管理菜單中選擇用戶信息管理選項2.選擇增加、刪除、修改、查詢課程信息操作3.輸入相關(guān)信息并確認教師信息包括：教師號、姓名、性別、密碼、手機、頭像學(xué)生信息包括：學(xué)號、姓名、性別、密碼、班級、頭像、手機號樓管信息包括：樓管賬號、姓名、性別、密碼、所處大樓、手機號其他人員信息包括：編號、姓名、性別、密碼、手機4.系統(tǒng)將相關(guān)數(shù)據(jù)保存到數(shù)據(jù)庫中4.3用例和場景表4-24用戶權(quán)限管理用例描述用例名稱用戶權(quán)限管理用例描述系統(tǒng)管理員修改指定的用戶權(quán)限參與者系統(tǒng)管理員基本路徑1.在用戶管理菜單中選中指定用戶2.點擊用戶權(quán)限管理按鈕3.對用戶權(quán)限進行增、刪、改操作4.單擊保存按鈕5.系統(tǒng)提示是否確認保存6.確認后，系統(tǒng)顯示保存成功圖4-13用戶管理用例圖4.4用戶故事地圖用戶故事（userstory）是從用戶角度來描述用戶渴望得到的功能。它是敏捷過程實踐中的一個重要環(huán)節(jié)。一個基本的用戶故事包括三個要素：角色、活動、商業(yè)價值，其一般描述格式：“作為什么角色，我想要進行什么活動（想要什么功能），以此來實現(xiàn)什么商業(yè)價值?！崩缫粋€故事可能是：作為學(xué)生可以查看他（她）的考勤記錄，以了解出勤情況。4.4.1用戶故事4.4用戶故事地圖極限創(chuàng)始人之一RonJeffries提出了一個關(guān)于用戶故事的3C描述：（1）卡片（Card）：用戶故事一般寫在小的記事卡片上。卡片上可能會寫上故事的簡短描述，工作量估算等。（2）交談（Conversation）：用戶故事背后的細節(jié)來源于和客戶或者產(chǎn)品負責(zé)人的交流溝通。（3）確認（Confirmation）：通過驗收測試確認用戶故事被正確完成。用戶故事通常由客戶團隊而不是開發(fā)人員編寫，每個客戶團隊?wèi)?yīng)包括確保軟件符合潛在用戶需求的相關(guān)人員。整個故事使用商業(yè)用語，而不是技術(shù)術(shù)語?？蛻魣F隊與開發(fā)人員共同確定故事細節(jié)并安排故事的優(yōu)先級順序。4.4.1用戶故事一個好的用戶故事應(yīng)該具有6個特性：1.獨立性（Independent）2.可協(xié)商性（Negotiable）3.對用戶或者客戶有價值（Valuable）4.可估算性（Estimable）5.短小（Small）6.可測試性（Testable）4.4用戶故事地圖4.4用戶故事地圖用戶故事與用例比較：用戶故事比用例的范圍更小。用例的主要目的是以客戶和開發(fā)人員都可以接受的格式，記錄客戶和開發(fā)團隊之間的協(xié)議。用例描述會涉及用戶界面和細節(jié)問題，并在整個軟件生命周期中都存在。用戶故事主要目的是用于溝通，啟動后期的分析和談話，它不涉及更多的細節(jié)，也不完全對應(yīng)于用例的主要正常場景，可以被存檔或者拋棄。4.4.1用戶故事4.4用戶故事地圖在編寫合理的用戶故事以后，需要對項目進行估算并制定各類的項目計劃。如果以用戶故事來描述系統(tǒng)功能，敏捷方法中通常會選用故事點來估算用戶故事。故事點是對故事復(fù)雜度、工作量或工期的相對估算。例如，一個故事點可以定義為沒有打擾情況下一個理想工作日所能完成的工作。4.4.2用戶故事估算和計劃4.4用戶故事地圖4.4.2用戶故事估算和計劃WidebandDelph估算法用迭代方式進行估算：1.所有參與的客戶和開發(fā)人員聚在一起，由客戶隨機抽取第一個故事開始，詳細講解故事直到所有人都清楚了解這個故事。2.然后每個開發(fā)人員以團隊共同定義的一個故事點可以完成的任務(wù)為單位，先寫下自己估算這個故事的完成時間。3.接著大家展示自己的估算，然后每個人解釋為什么估算出這個值。4.經(jīng)過討論和再次個人估算，直到經(jīng)過論證，團隊估算出一個所有人都認可的值，再繼續(xù)下一個故事的估算。4.4用戶故事地圖4.4.2用戶故事估算和計劃在估算數(shù)個故事后，對估算結(jié)果做三角測量：在估算一個故事時，根據(jù)這個故事與其他一個或多個故事的關(guān)系來估算。假定一個故事估算為4個故事點，第二個故事為2個故事點，把這兩個故事放在一起考慮的時候，程序員都應(yīng)該認可4個故事點的故事大小是2個故事點的故事的2倍，其他3個故事點的故事的大小應(yīng)該介于4個故事點的故事和2個故事點的故事之間。如果上面的三角測量的結(jié)果不對，團隊就應(yīng)該重新估算。4.4用戶故事地圖4.4.3用戶故事地圖JeffPatton提出用戶故事地圖（UserStoryMapping），以結(jié)構(gòu)化的方式來組織用戶故事圖4-14用戶故事地圖舉例4.4用戶故事地圖4.4.3用戶故事地圖圖4-15智慧教室用戶故事地圖的脈絡(luò)5個主要步驟：（1）產(chǎn)品的定義（2）梳理骨干故事（3）拆分故事（4）確定優(yōu)先級和發(fā)布計劃（5）反饋修正故事小結(jié)1.了解有關(guān)需求的基本知識。2.掌握需求工程的主要活動及它們之間的關(guān)系。3.掌握需求獲取主要方法。4.掌握通過用例和場景對需求建模。5.掌握用戶故事地圖建立項目需求。作業(yè)與思考作業(yè)：1.試對智慧教室的物聯(lián)設(shè)備做進一步探究，了解相關(guān)的應(yīng)用領(lǐng)域

，建立物聯(lián)設(shè)備的術(shù)語表。2.請設(shè)計教材以外的一個智慧教室的應(yīng)用場景，并對本節(jié)中的用例加以改進。3.請給出“查看考勤結(jié)果”用例描述。4.選取一個實例，用用戶故事地圖來建立實例的二維視圖。思考：1.如何理解“如果產(chǎn)品能以20%的功能滿足80%的人的需求，那么這個產(chǎn)品就成功了一大步”這句話。它的背后隱含著什么定律或者原則。第5章

需求分析本章學(xué)習(xí)目標(biāo)1.理解需求分析的主要任務(wù)。2.理解不同需求分析方法解決問題的本質(zhì)3.掌握傳統(tǒng)的結(jié)構(gòu)化分析方法。4.掌握面向?qū)ο蟮姆治龇椒ā?.熟練應(yīng)用UML建立需求分析模型。6.了解軟件形式化分析技術(shù)。

面向數(shù)據(jù)流的結(jié)構(gòu)化分析1形式化分析技術(shù)5結(jié)構(gòu)化分析實例2面向?qū)ο蟮姆治?面向?qū)ο蠓治鰧嵗?需求分析的主要任務(wù)在需求工程的起始階段，項目利益相關(guān)者建立起基本的問題需求，定義重要的項目約束條件并描述項目的功能和主要特征。這些信息經(jīng)過各種需求收集活動后，在需求導(dǎo)出階段記錄下來。在進入需求的精化階段，需求會得到進一步的精煉，并擴展為分析模型。創(chuàng)建需求分析模型原則Ariow和Neustadt提出了在創(chuàng)建需求分析模型時應(yīng)注意的原則：（1）分析模型應(yīng)關(guān)注問題域或業(yè)務(wù)域內(nèi)可見的需求，并注意提高抽象級別。（2）分析模型的每個元素都應(yīng)能增加對軟件需求的整體理解，并提供對信息域、功能和系統(tǒng)行為域的深入理解。（3）關(guān)于基礎(chǔ)結(jié)構(gòu)和其他非功能的模型應(yīng)推遲到設(shè)計階段再考慮。（4）應(yīng)最小化整個系統(tǒng)內(nèi)的關(guān)聯(lián)，減少類和功能間的直接依賴關(guān)系和相互作用。（5）確認分析模型為項目所有利益相關(guān)者都能帶來價值。（6）盡可能保持模型簡潔。需求建模方法在需求建模過程中，軟件工程具體關(guān)注的焦點是“系統(tǒng)要做什么”，而不是“系統(tǒng)該怎么做”。關(guān)注的主要問題有“在特定的應(yīng)用環(huán)境下，發(fā)生了哪些用戶交互？系統(tǒng)處理哪些對象？系統(tǒng)必須執(zhí)行什么功能？系統(tǒng)對外界展示什么行為？系統(tǒng)與外界有哪些接口？受到什么樣的約束？”等。需求建模方法傳統(tǒng)的面向數(shù)據(jù)和面向處理的需求建模方法被稱為結(jié)構(gòu)化分析，其中處理是將數(shù)據(jù)作為獨立實體加以轉(zhuǎn)換，表示了數(shù)據(jù)對象在系統(tǒng)內(nèi)流動時，系統(tǒng)是如何處理和如何轉(zhuǎn)換數(shù)據(jù)。面向?qū)ο蟮男枨蠓治龇椒?，則是關(guān)注于識別和定義類，通過類之間的協(xié)作來響應(yīng)客戶的需求。5.1.1半形式化分析技術(shù)（1）數(shù)據(jù)流圖數(shù)據(jù)流圖有時也被稱為數(shù)據(jù)流程圖（DataFlowDiagram，簡稱DFD），是一種便于用戶理解和分析系統(tǒng)數(shù)據(jù)流程的圖形工具。表5-1數(shù)據(jù)流程圖基本符號5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析在繪制分層數(shù)據(jù)流圖時應(yīng)注意以下事項：①自頂向下、逐層分解。②數(shù)據(jù)流必須經(jīng)過加工環(huán)節(jié)。③每個加工必須既有輸入數(shù)據(jù)流，又有輸出數(shù)據(jù)流。④數(shù)據(jù)存儲環(huán)節(jié)一般作為兩個加工環(huán)節(jié)的界面來安排。⑤適當(dāng)?shù)貫閿?shù)據(jù)流、加工、數(shù)據(jù)存儲、外部實體命名，名字應(yīng)反映該成分的實際含義，避免空洞的名字。在繪制分層數(shù)據(jù)流圖時應(yīng)注意以下事項：⑥編號。⑦保持數(shù)據(jù)守恒。⑧局部數(shù)據(jù)存儲的隱蔽性。⑨保持父圖與子圖平衡。⑩只繪制所描述的系統(tǒng)穩(wěn)定工作情況下的數(shù)據(jù)流圖。?畫數(shù)據(jù)流而不要畫控制流。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析（2）判定樹和判決表判定樹又稱決策樹（decisiontree），是一種描述加工的圖形工具，適合描述問題處理中具有多個判斷，并且每個決策與若干條件有關(guān)，導(dǎo)致不同的結(jié)果。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析例如有關(guān)退票改簽費有如下規(guī)定：

開車前8天（不含）以上退票的，不收取退票費；票面乘車站開車時間前48小時以上的按票價5%計，24小時以上、不足48小時的按票價10%計，不足24小時的按票價20%計。辦理車票改簽時，新車票票價高于原車票的，收取票價差額。新車票票價等于原車票，不收取費用。新車票票價低于原車票的，退還差額。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析圖5-1判定樹表示購票5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析表5-2購買火車票判定表5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析（3）數(shù)據(jù)字典數(shù)據(jù)字典是元數(shù)據(jù)(metadata)的結(jié)構(gòu)化存儲庫，它提供所用數(shù)據(jù)的全面描述。其主要目的是提供一種共同的語言，以幫助軟件項目的涉眾理解數(shù)據(jù)、數(shù)據(jù)的含義以及數(shù)據(jù)與其他數(shù)據(jù)元素的關(guān)系。在結(jié)構(gòu)化分析中，數(shù)據(jù)字典的作用是給數(shù)據(jù)流圖中每個成分加以定義和說明，數(shù)據(jù)流圖和數(shù)據(jù)字典共同構(gòu)成系統(tǒng)的邏輯模型。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析1.數(shù)據(jù)項：數(shù)據(jù)流圖中數(shù)據(jù)塊的數(shù)據(jù)結(jié)構(gòu)中的數(shù)據(jù)項說明。數(shù)據(jù)項描述={數(shù)據(jù)項名，數(shù)據(jù)項含義說明，別名，數(shù)據(jù)類型，長度，取值范圍，取值含義，與其他數(shù)據(jù)項的邏輯關(guān)系}2.數(shù)據(jù)結(jié)構(gòu)：數(shù)據(jù)流圖中數(shù)據(jù)塊的數(shù)據(jù)結(jié)構(gòu)說明。數(shù)據(jù)結(jié)構(gòu)描述={數(shù)據(jù)結(jié)構(gòu)名，含義說明，組成：{數(shù)據(jù)項或數(shù)據(jù)結(jié)構(gòu)}}3.數(shù)據(jù)流：數(shù)據(jù)流圖中流線的說明。數(shù)據(jù)流描述={數(shù)據(jù)流名，說明，數(shù)據(jù)流來源，數(shù)據(jù)流去向，組成：{數(shù)據(jù)結(jié)構(gòu)}，平均流量，高峰期流量}4.數(shù)據(jù)存儲：數(shù)據(jù)流圖中數(shù)據(jù)塊的存儲特性說明。數(shù)據(jù)存儲描述={數(shù)據(jù)存儲名，說明，編號，流入的數(shù)據(jù)流，流出的數(shù)據(jù)流，組成：{數(shù)據(jù)結(jié)構(gòu)}，數(shù)據(jù)量，存取方式}5.處理過程：數(shù)據(jù)流圖中功能塊也就是加工的說明。處理過程描述={處理過程名，說明，輸入：{數(shù)據(jù)流}，輸出：{數(shù)據(jù)流}，處理：{簡要說明}}5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析5.1.2

Gane和Sarsen結(jié)構(gòu)化系統(tǒng)分析Gane和Sarsen的結(jié)構(gòu)化系統(tǒng)分析方法作為主流的傳統(tǒng)需求分析技術(shù)是以系統(tǒng)中數(shù)據(jù)流動為重點，對數(shù)據(jù)出入系統(tǒng)邊界形態(tài)、系統(tǒng)內(nèi)部處理進行研究來分析用戶的要求。其分析過程分為9個步驟。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析分析過程分為以下9個步驟：（1）在需求初步獲取的基礎(chǔ)上運用逐步求精的方法畫數(shù)據(jù)流圖，數(shù)據(jù)流圖分層描述。（2）決定軟件系統(tǒng)實現(xiàn)數(shù)據(jù)流圖中哪些部分。（3）確定數(shù)據(jù)流圖中數(shù)據(jù)流的細節(jié)。（4）定義數(shù)據(jù)流圖中加工的處理邏輯。（5）定義數(shù)據(jù)流圖中涉及的數(shù)據(jù)存儲。（6）定義滿足項目需要的物理資源。（7）確定項目需要滿足的輸入－輸出規(guī)格說明。（8）確定系統(tǒng)中輸入數(shù)據(jù)、中間計算結(jié)果、輸出數(shù)據(jù)的大小。（9）根據(jù)步驟（8）中的計算結(jié)果，確定硬件要求和約束。5.1面向數(shù)據(jù)流的結(jié)構(gòu)化分析5.2結(jié)構(gòu)化分析實例5.2.1逐步求精數(shù)據(jù)流圖智慧教室是一個較為復(fù)雜的問題，一次性得到一張完整的DFD比較困難，可以按照系統(tǒng)抽象層次結(jié)構(gòu)進行逐步求精，并采用分層數(shù)據(jù)流圖表示。圖5-2頂層數(shù)據(jù)流圖圖5-3第一次細化數(shù)據(jù)流圖5.2結(jié)構(gòu)化分析實例圖5-4課堂管理細化數(shù)據(jù)流圖5.2結(jié)構(gòu)化分析實例圖5-5人臉考勤管理細化數(shù)據(jù)流圖5.2結(jié)構(gòu)化分析實例5.2.2定義數(shù)據(jù)字典表5-3人臉考勤管理數(shù)據(jù)字典部分詞條5.2結(jié)構(gòu)化分析實例5.2.3建造實體-關(guān)系模型5.2結(jié)構(gòu)化分析實例面向?qū)ο蠓治?.3.1面向?qū)ο蠓椒ê徒Y(jié)構(gòu)化方法結(jié)構(gòu)化方法求解問題的基本策略是從功能的角度審視問題域。它將應(yīng)用程序看成實現(xiàn)某些特定任務(wù)的功能模塊。在每個功能模塊中，用數(shù)據(jù)結(jié)構(gòu)描述待處理數(shù)據(jù)的組織形式，用算法描述具體的操作過程。在面向?qū)ο蟮募夹g(shù)中，對象由數(shù)據(jù)和操作組成。對程序設(shè)計者而言，對象是一個具有信息性內(nèi)聚的程序模塊；對其他用戶而言，對象是程序提供給他們的服務(wù)，通過知悉對象接口形式就可以調(diào)用，并不需要了解它們的內(nèi)部實現(xiàn)細節(jié)。5.3面向?qū)ο蠓治?.3.2面向?qū)ο蠓治鲋械闹饕夹g(shù)面向?qū)ο蠓治觯∣OA）是一種半形式化的分析技術(shù)。在多種面向?qū)ο蟮能浖こ谭椒ㄖ校容^有影響的應(yīng)用有Booch、OOSE、OMT，以及后面出現(xiàn)的統(tǒng)一過程等。5.3面向?qū)ο蠓治?.3.2面向?qū)ο蠓治鲋械闹饕夹g(shù)GradyBooch是面向?qū)ο蠓椒ㄗ钤绲某珜?dǎo)者之一。他于1986年提出了“面向?qū)ο蠓治雠c設(shè)計（OOAD）”。

Booch提出的開發(fā)模型包括邏輯模型、物理模型、靜態(tài)模型和動態(tài)模型。①發(fā)現(xiàn)類和對象，在一定抽象層面標(biāo)識出類和對象；②確定類和對象的語義，將期望的行為賦予對象類；③標(biāo)識類和對象之間的關(guān)系。Booch方法有很強的表達能力，其迭代和增量的思想對很多軟件工程開發(fā)設(shè)計階段的建模提供了重要的指導(dǎo)。5.3面向?qū)ο蠓治鯫MT（ObjectModelingTechnique）方法是由Loomis，Shan和JamesRumbaugh在最先提出的實體和關(guān)系模型基礎(chǔ)上進一步擴展了類、行為以及繼承等得來。①對象模型：表述對象靜態(tài)的結(jié)構(gòu)以及它們之間的相互作用關(guān)系。②動態(tài)模型：描述系統(tǒng)動態(tài)的變化特點，包括狀態(tài)和活動等。③功能模型：描述與數(shù)據(jù)值的變換有關(guān)的系統(tǒng)特征，不同數(shù)據(jù)值之間在系統(tǒng)內(nèi)的轉(zhuǎn)換，包括處理、數(shù)據(jù)存儲、數(shù)據(jù)流等概念。5.3面向?qū)ο蠓治鯦acobson提出了“面向?qū)ο筌浖こ蹋∣OSE）”方法，其核心是用例驅(qū)動，建立面向?qū)ο蟮姆治瞿Ｐ秃驮O(shè)計模型。主要用五種模型來描述系統(tǒng)：①需求模型（Requirementmodel，簡稱RM）。②分析模型（Analysismodel，AM）。③設(shè)計模型（Designmodel，簡稱DM）。④實現(xiàn)模型（Implementationmodel，IM）。⑤測試模型（Testingmodel，簡稱TM）。OOSE的開發(fā)活動主要包括分析、構(gòu)造、測試三個過程。5.3面向?qū)ο蠓治鼋y(tǒng)一過程使用統(tǒng)一建模語言（UnifiedModelingLanguage，簡稱UML）來表示要開發(fā)的軟件。UML是面向?qū)ο箝_發(fā)中一種通用的圖形化建模語言?；赨ML建?？梢苑譃殪o態(tài)和動態(tài)兩類：基于用例圖、對象圖以及類圖等創(chuàng)建的模型為靜態(tài)模型，基于狀態(tài)圖、活動圖等創(chuàng)建的模型為動態(tài)模型。表5-4UML部分語法描述5.3面向?qū)ο蠓治?.3.3面向?qū)ο蟮姆治龇椒ê椭饕襟E面向?qū)ο蠓治龅哪繕?biāo)主要是完成對求解問題的分析，建立系統(tǒng)的需求分析模型，包括對象模型、動態(tài)模型和功能模型等。（1）對象模型：對用例模型進行分析，把系統(tǒng)分解成互相協(xié)作的分析類，通過類圖和對象圖描述對象、對象的屬性以及對象間的關(guān)系。對象模型是對系統(tǒng)的靜態(tài)建模。（2）動態(tài)模型：描述系統(tǒng)的動態(tài)行為，通過順序圖、協(xié)作圖描述對象的交互，以揭示對象間如何協(xié)作來完成每個具體的用例。單個對象的狀態(tài)變化、動態(tài)行為可以通過狀態(tài)圖來表示。（3）功能模型：描述系統(tǒng)應(yīng)該做什么，最直接地反映了用戶對目標(biāo)系統(tǒng)的需求。通常功能模型由一組數(shù)據(jù)流圖或一組用例圖組成。5.3面向?qū)ο蠓治?.3.3面向?qū)ο蟮姆治龇椒ê椭饕襟E可以把面向?qū)ο蟮姆治鲞^程分成三個主要活動：用例建模、類建模和動態(tài)建模。(1)

用例建模：建立以用例模型為主體的需求模型，提出所有用例的場景，又稱功能建模。(2)類建模：確定類和它們的屬性，以及類間的相互關(guān)系和交互作用。(3)動態(tài)建模：確定由每個類或者子類執(zhí)行的活動或?qū)λ鼈冞M行的行為。5.3面向?qū)ο蠓治?.3.3面向?qū)ο蟮姆治龇椒ê椭饕襟E面向?qū)ο蠓治鰪某槿☆愰_始。5.3表5-5

類的構(gòu)造表達面向?qū)ο蠓治?.3.3面向?qū)ο蟮姆治龇椒ê椭饕襟E實體類的提取可以按照如下步驟進行：1）提出所有用例的可能場景，包括正常場景和異常場景。2）標(biāo)識出這些用例和場景中的實體類（包括屬性和方法，

也可以在面向?qū)ο笤O(shè)計時深入探索）。3）確定實體類結(jié)構(gòu)和層次。4）確定實體類之間的交互關(guān)系。5.3面向?qū)ο蠓治?.3.3面向?qū)ο蟮姆治龇椒ê椭饕襟E用例是系統(tǒng)功能的一般性描述，場景是用例的一個特定實例。系統(tǒng)每個用例可以通過由實體類、邊界類、控制類相互關(guān)聯(lián)的類圖來表示。用例的場景通過這些類的對象之間的交互關(guān)系和交互行為來實現(xiàn)，可以通過順序圖、協(xié)作圖等來對這個場景進行動態(tài)建模。在面向?qū)ο蠓治鲞^程中，有多種方法可以幫助提取實體類。5.3面向?qū)ο蠓治?.3.3面向?qū)ο蟮姆治龇椒ê椭饕襟E（1）用例識別從用例和場景中識別類是提取類的一種主要方法。針對每個用例，我們可以通過回答以下問題來識別出候選類：①用例或者場景描述，需要哪些實體參與合作以完成任務(wù)？②用例或者場景描述中，會生成或者存儲哪些需要長期保存的信息？③用例使用者需要向用例輸入的信息有哪些？④用例向使用者輸出的信息有哪些？⑤用例需要對哪些設(shè)備進行操作？5.3面向?qū)ο蠓治觯?）名詞識別法首先用指定語言對系統(tǒng)進行簡要的描述，通常用一個段落即可；接著從這段描述中標(biāo)識出名詞、代詞、名詞短語，并將其表示成初始的候選類；然后通過回答以下問題進一步確定類。①是否存在兩個及以上類，表述的是同一個信息，刪除冗余的候選類，僅保留一個具有描述能力的候選類。②刪除處于系統(tǒng)邊界之外的類，即去掉不相干的候選類。③刪除定義不確切，或者范圍過大的模糊的候選類。④刪除獨立性不清，應(yīng)該屬于類的屬性的候選類。⑤刪除獨立性不強，應(yīng)該屬于類的操作的候選類。5.3面向?qū)ο蠓治觯?）CRC卡片1990年Wiener提出了類—職責(zé)—協(xié)作建模（Class-Responsibility-Collaboration，簡稱CRC）。CRC模型在開始時是用卡片記錄，將每個類的類名、功能（職責(zé)）和它要需要調(diào)用其他類的列表放在一張卡片中。5.35.4.1功能建模表5-6查看考勤結(jié)果用例場景描述面向?qū)ο蠓治鰧嵗?.45.4.1功能建模圖5-7查看考勤結(jié)果活動圖面向?qū)ο蠓治鰧嵗?.4面向?qū)ο蠓治鰧嵗?.4.1功能建模表5-8

活動圖基本組成描述5.45.4.2類建模根據(jù)人臉考勤用例可以得到下列類：（1）實體類①考勤記錄：記錄用戶每一次的考勤結(jié)果。②采集人臉信息：保存教室現(xiàn)場采集的考勤人臉特征信息。③學(xué)生信息：保存學(xué)生信息包括學(xué)生人臉信息。（2）控制類①人臉考勤：負責(zé)處理考勤過程中系統(tǒng)特定指令和動作。（3）邊界類①攝像頭接口：負責(zé)獲取教室圖像信息。②教師界面：教師與系統(tǒng)交流的媒介。面向?qū)ο蠓治鰧嵗?.45.4.2類建模圖5-8考勤管理用例的初始類圖面向?qū)ο蠓治鰧嵗?.45.4.2類建模圖5-9用戶管理用例的初始類圖面向?qū)ο蠓治鰧嵗?.45.4.2類建模圖5-10智慧教室管理系統(tǒng)部分用例合并得到的初始類圖面向?qū)ο蠓治鰧嵗?.45.4.3動態(tài)建模

（1）狀態(tài)圖表5-9狀態(tài)圖基本組成描述面向?qū)ο蠓治鰧嵗?.45.4.3動態(tài)建模

在狀態(tài)圖中，事件（Event）、動作（Action）、以及活動（Activity），在描述狀態(tài)之間的轉(zhuǎn)換和狀態(tài)行為時起著關(guān)鍵作用。事件是引起狀態(tài)轉(zhuǎn)換或觸發(fā)狀態(tài)中行為的觸發(fā)器。它可以是外部的信號、條件的改變、用戶的操作等。事件表示狀態(tài)變化的原因或起因。動作是在狀態(tài)機中執(zhí)行的某種行為或操作，它通常與狀態(tài)轉(zhuǎn)換相關(guān)聯(lián)，描述了狀態(tài)從一個狀態(tài)到另一個狀態(tài)的具體動作。動作是狀態(tài)機中可以執(zhí)行的原子操作。活動是狀態(tài)機中一個狀態(tài)執(zhí)行的一系列操作或任務(wù)。它是狀態(tài)中進行的非原子操作，可以描述狀態(tài)內(nèi)部的活動流程，而不是僅僅描述狀態(tài)之間的轉(zhuǎn)換。面向?qū)ο蠓治鰧嵗?.45.4.3動態(tài)建模

（1）狀態(tài)圖圖5-11學(xué)生考勤狀態(tài)圖面向?qū)ο蠓治鰧嵗?.45.4.3動態(tài)建模

（2）順序圖表5-10順序圖基本組成描述面向?qū)ο蠓治鰧嵗?.45.4.3動態(tài)建模

（2）順序圖圖5-12人臉考勤順序圖面向?qū)ο蠓治鰧嵗?.45.4.3動態(tài)建模

（2）順序圖圖5-13教師查詢考勤記錄順序圖面向?qū)ο蠓治鰧嵗?.45.4.3動態(tài)建模

（3）協(xié)作圖表5-11協(xié)作圖中的部分符號面向?qū)ο蠓治鰧嵗?.45.4.3動態(tài)建模

（3）協(xié)作圖圖5-14教師查詢考勤結(jié)果協(xié)作圖面向?qū)ο蠓治鰧嵗?.4形式化分析技術(shù)形式化方法（FormalMethods）是驗證軟件系統(tǒng)是否高度安全可靠的重要方法，是提高軟件質(zhì)量的有效途徑。在軟件工程領(lǐng)域，形式化方法是基于數(shù)學(xué)的描述和驗證軟件系統(tǒng)的一種方法。形式化方法利用數(shù)學(xué)的嚴(yán)密性去證明系統(tǒng)的正確性，形成一套嚴(yán)密的理論體系，提供一個完整的框架，使得人們可以在這個框架中以一種系統(tǒng)的方式描述和驗證軟件系統(tǒng)。5.5形式化方法可以分為以下五類：（1）基于模型的方法：通過明確定義狀態(tài)和操作來建立一個系統(tǒng)模型，顯式說明系統(tǒng)如何從一個狀態(tài)轉(zhuǎn)換到另一個狀態(tài)，例如Z語言、VDM和B方法等。（2）基于網(wǎng)絡(luò)的方法：采用具有形式語義的圖形語言，例如Petri網(wǎng)、狀態(tài)機等。（3）進程代數(shù)方法：通過限制所有容許的可觀察的進程間通信來表示系統(tǒng)行為，允許并發(fā)進程的顯式表示，例如通信順序進程CSP、通信系統(tǒng)演算CCS、時序排序規(guī)約語言LOTOS、計時通信順序進程TCSP、計時可能性演算TPCCS等。形式化分析技術(shù)5.5形式化方法可以分為以下五類：（4）基于邏輯的方法：用邏輯描述系統(tǒng)底層規(guī)約、時序和行為等，采用與所選邏輯相關(guān)的公理系統(tǒng)證明系統(tǒng)達到預(yù)期目標(biāo)。利用具體的編程構(gòu)造擴充邏輯，通過保持正確性的細化步驟集來開發(fā)系統(tǒng)。這類方法有各類時序邏輯TL、hoare邏輯、WP演算、模態(tài)邏輯等。（5）代數(shù)方法：通過將未定義狀態(tài)下不同的操作行為相聯(lián)系，給出操作的顯式定義。這類方法有OBJ、Larch族代數(shù)規(guī)約語言等。形式化分析技術(shù)5.5汽車無鑰匙進入系統(tǒng)CSP模型//模型需要的常量定義#defineN2;//車鑰匙擁有者數(shù)目（2人）#definefar0;//人離汽車遠#definenear1;//人離汽車近，有鑰匙的話可以開車門#definein2;//人在車?yán)?defineoff0;//汽車發(fā)動機關(guān)#defineon1;//汽車發(fā)動機開#defineunlock0;//車門關(guān)閉但沒鎖#definelock1;//車門鎖住#defineopen2;//車門開著#defineincar-1;//鑰匙在車?yán)?definefaralone-2;//鑰匙不在車?yán)锴译x車很遠形式化分析技術(shù)5.5//模型需要的變量定義varowner[N]={far,far};//人的位置，編號分別是0和1，初始時2人都離車很遠varengine=off;//發(fā)動機狀態(tài)，初始時關(guān)閉vardoor=lock;//車門的狀態(tài)，初始時門是鎖住的varkey=0;//車鑰匙歸屬，初始時在0號人處varmoving=0;//汽車移動狀態(tài)，0是停止，1是移動varfuel=10;//發(fā)動機油耗，1表示短距離，5表示長距離//人的行為模型，其中i表示人的編號（這個模型中可以是0也可以是1），“[]”表示前后連接的行為可以任意選擇，“[條件]”表示滿足條件才能進行條件后的行為（斜體字部分），“{運算}”表示行為發(fā)生時改變一些變量的值，箭頭表示行為發(fā)生先后順序，“&&”和“||”分別表示邏輯并或者邏輯或owner_pos(i)=[owner[i]==far]towards.i{owner[i]=near;}->owner_pos(i)[][owner[i]==near]goaway.i{owner[i]=far;}->owner_pos(i)[][owner[i]==near&&door==open&&moving==0]getin.i{owner[i]=in;}->owner_pos(