結(jié)構(gòu)化的需求分析與建模課件

第四章結(jié)構(gòu)化分析與建模（一）4.1

需求建模概述與結(jié)構(gòu)化建模4.2數(shù)據(jù)模型與ER圖本章結(jié)構(gòu)4.3功能模型－數(shù)據(jù)流圖4.4行為模型－狀態(tài)轉(zhuǎn)換圖4.5數(shù)據(jù)字典4.6判定表和判定樹結(jié)構(gòu)化的需求分析與建模

“化學制品跟蹤系統(tǒng)”的項目開發(fā)組正在進行第一次軟件需求規(guī)格說明的評審。參加者有Dave（項目經(jīng)理），Lori（需求分析者），Helen(高級程序員)，Ramesh(測試專家)，Tim(化學制品的產(chǎn)品代表者)，還有Roxanne(化學制品倉庫的產(chǎn)品代表者)。

Tim開始說：“我閱讀過整個軟件需求規(guī)格說明。大部分都符合我的需求，但是有幾個部分我很難同意。我不能確信在化學制品請求過程中，我們是否確定了這些步驟?！盧amesh又補充說：“當一個請求通過系統(tǒng)時，我很難想象用于覆蓋該請求狀態(tài)變化的所有測試用例。我發(fā)現(xiàn)許多關于狀態(tài)變化的需求散布在整個軟件需求規(guī)格說明中，但我無法確定是否有一些需求遺漏了或存在不一致性?！币耘c要點結(jié)構(gòu)化的需求分析與建模Roxanne有一個類似的問題?！爱斘议喿x了如何真正請求一種化學藥品時，我感到困惑”，她說，“單個需求是能感覺到的，但我難以想像我所要完成的步驟順序?！痹诟髟u審員提出其它相關的問題后，Lori做出了總結(jié)：“看來軟件需求規(guī)格說明似乎沒有完全告訴我們對于理解系統(tǒng)所需的各個方面，也不能確保我們沒有錯過一個需求或不犯任何錯誤。我將畫一些圖來幫助我們想像這些需求，并看一下能否澄清這些問題域。謝謝你們的反饋意見?！币耘c要點結(jié)構(gòu)化的需求分析與建模相關基礎概念所謂模型，就是為了理解事物而對該事物做出的一種抽象，在軟件工程中的模型由一組圖形符號和組織這些符號的規(guī)則組成

。經(jīng)過對需求獲取的資料進行分析，并以此建立起來的模型稱之為需求分析模型。結(jié)構(gòu)化的需求分析與建模引言與要點需求分析模型主要描述軟件目標系統(tǒng)的數(shù)據(jù)信息、處理功能、用戶界面及運行的外部行為，它并不涉及軟件的具體實現(xiàn)細節(jié)。模型幫助分析員理解系統(tǒng)的信息、功能和行為；模型成為評審焦點；模型也是設計基礎。建模充分體現(xiàn)了“分而治之”這一古老而有效的概念。把復雜而困難的問題分解細化后，逐個解決它們。建模能有效地將需求映射到軟件結(jié)構(gòu)中。＃BK結(jié)構(gòu)化的需求分析與建模第四章結(jié)構(gòu)化分析與建模（一）4.1

需求建模概述與結(jié)構(gòu)化建模4.2數(shù)據(jù)模型與ER圖本章結(jié)構(gòu)4.3功能模型－數(shù)據(jù)流圖4.4行為模型－狀態(tài)轉(zhuǎn)換圖4.5數(shù)據(jù)字典4.6判定表和判定樹結(jié)構(gòu)化的需求分析與建模需求分析階段模型的作用幫助系統(tǒng)分析員理解系統(tǒng)的信息、功能和行為，使得需求分析任務更加容易實現(xiàn)，結(jié)果更加系統(tǒng)化。它是評審焦點，是確定SRS完整性、一致性和精確性的重要依據(jù)。它是設計的基礎，是軟件要素的表示視圖。結(jié)構(gòu)化的需求分析與建模從客戶需求到分析模型認真聽取客戶陳述他們的需求之后，分析人員就可以挑選出關鍵字，將這些關鍵字轉(zhuǎn)換成特定的模型元素。表4.1列出了一些可能的映射：結(jié)構(gòu)化的需求分析與建模單詞類型

示例分析模型組件名詞

人、組織、軟件系統(tǒng)、數(shù)據(jù)項或存在的對象

數(shù)據(jù)存儲(DFD)

執(zhí)行者(用例圖)

實體或?qū)嶓w屬性(ERD)

類或類屬性(類圖)

動詞

動作、用戶可做的事情或可能發(fā)生的事件

處理過程(DFD)

用例(用例圖)

關系(ERD)

狀態(tài)(STD)

活動(活動圖)

表4.1映射示例結(jié)構(gòu)化的需求分析與建模

“一位化學家或化學品倉庫保管人員可以提出獲得一種或多種化學制品的請求：一是提供一個存在于化學制品倉庫清單上的化學品容器，二是向外界供應商提交一份訂購新的化學品的訂單。提出請求的人在準備其請求時，必須能夠通過在線查找供應商目錄表找到特定的化學品。從準備請求直到執(zhí)行請求或取消請求期間，系統(tǒng)必須跟蹤每一個化學品請求的狀態(tài)。系統(tǒng)還必須跟蹤每個化學品的歷史記錄，從公司收到化學品直到它完全被用盡或丟棄為止?！被瘜W制品跟蹤系統(tǒng)示例結(jié)構(gòu)化的需求分析與建模結(jié)構(gòu)化分析的模型結(jié)構(gòu)化分析是一種建立模型的活動，創(chuàng)建描述信息內(nèi)容和信息流的模型，依據(jù)功能和行為對系統(tǒng)進行劃分。建模時,需要關注系統(tǒng)最復雜和風險最大的部分，以及最容易產(chǎn)生歧義和不確定性的部分。結(jié)構(gòu)化的需求分析與建模結(jié)構(gòu)化分析的模型結(jié)構(gòu)化分析模型圖結(jié)構(gòu)化的需求分析與建模4.2數(shù)據(jù)模型與ER圖數(shù)據(jù)模型包括三種互相關聯(lián)的信息：數(shù)據(jù)對象、描述數(shù)據(jù)對象的屬性和數(shù)據(jù)對象相互連接的關系。1.數(shù)據(jù)對象是一個外部實體、一個事物（如報告）、一次行為（如電話呼叫）或事件（一個警報）、一個角色（如銷售人員）、一個組織單元（如銷售部門、人事部門）、一個地點（如倉庫）或一個結(jié)構(gòu)（如文件）。結(jié)構(gòu)化的需求分析與建模4.2數(shù)據(jù)模型與ER圖如，人或車可以被認為是數(shù)據(jù)對象，因為它們可以用一組屬性來定義?！皵?shù)據(jù)對象描述”包括了數(shù)據(jù)對象及其所有的屬性。數(shù)據(jù)模型只封裝了數(shù)據(jù)，沒有對數(shù)據(jù)的操作。結(jié)構(gòu)化的需求分析與建模2.屬性屬性定義了數(shù)據(jù)對象的性質(zhì)，數(shù)據(jù)對象有許多屬性，應選擇一組本質(zhì)的屬性。例如，教師的屬性有教工號、姓名、性別、職稱、專業(yè)、研究方向、擔任課程、住址、電話等。如果設計“教學管理系統(tǒng)”，關心與教學有關的屬性、排除與教學無關的屬性。結(jié)構(gòu)化的需求分析與建模3.關系數(shù)據(jù)對象是相互關聯(lián)的，如人可以“擁有”車。擁有即它們間的一種關系。實體和實體之間的關系被抽象為聯(lián)系。聯(lián)系分為：

1)一對一（1:1）（一個丈夫只能有一個妻子）

2)一對多（1:N）(一個母親有多個孩子)

3)多對多（M:N）(侄子與叔叔)結(jié)構(gòu)化的需求分析與建模實體—關系圖概念最常使用的數(shù)據(jù)模型是實體—關系圖(Entity-RelationshipDiagram，ERD)實體用單名詞來命名，在實體-關系圖中用矩形框來表示實體。實體—關系圖中的菱形框代表關系，它確定了一對實體之間在邏輯上和數(shù)量上的連接。關系的命名要能描述關系的本質(zhì)。主鍵:能唯一地標識該實體的屬性或?qū)傩越M。結(jié)構(gòu)化的需求分析與建模ERD的圖例結(jié)構(gòu)化的需求分析與建模ERD的實例圖4-2-1“某校課程管理系統(tǒng)”的實體聯(lián)系圖結(jié)構(gòu)化的需求分析與建模某一學校擬開發(fā)一課程管理系統(tǒng)，假設系統(tǒng)主要由老師、課程、學生和教室等實體組成，各實體的屬性組成如下：學生（學號、姓名、性別、系別、專業(yè)。。。）課程（課程編號、課名、學時、學分。。。）教師（編號、姓名、職稱、性別、系別。。。）教室（代號、名稱、樓號、房號、地點。。。）請將實體教室和老師、課程、學生的屬性補充進上頁ER圖。課程管理系統(tǒng)ER圖編制說明結(jié)構(gòu)化的需求分析與建模圖4-2-2“化學制品跟蹤系統(tǒng)”的實體聯(lián)系圖結(jié)構(gòu)化的需求分析與建模

4.3功能模型－數(shù)據(jù)流圖數(shù)據(jù)流模型把功能分解方法運用到系統(tǒng)分析上，把復雜的問題進一步分解到更詳細的層次。數(shù)據(jù)流模型很適用于事務處理系統(tǒng)和其他功能密集型應用程序。結(jié)構(gòu)化的需求分析與建模數(shù)據(jù)流圖四種基本圖形符號數(shù)據(jù)流圖有四種基本圖形符號：結(jié)構(gòu)化的需求分析與建模畫數(shù)據(jù)流程圖的原則①數(shù)據(jù)流程圖上所有圖形符號必須是前面所述的四種基本元素。②數(shù)據(jù)流程圖的主圖必須含有前面所述的四種基本元素，缺一不可。③數(shù)據(jù)流程圖上的數(shù)據(jù)流必須封閉在外部實體之間，外部實體可以是一個，也可以是多個。4.3功能模型－數(shù)據(jù)流圖結(jié)構(gòu)化的需求分析與建模畫數(shù)據(jù)流程圖的原則④處理過程至少有一個輸入數(shù)據(jù)流和一個輸出數(shù)據(jù)流。⑤任何一個數(shù)據(jù)流子圖必須與它的父圖上的一個處理過程對應，兩者的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流必須一致，即所謂“平衡”。

⑥數(shù)據(jù)流程圖上的每個元素都必須有名字。

4.3功能模型－數(shù)據(jù)流圖結(jié)構(gòu)化的需求分析與建模為方便儲戶，某銀行擬開發(fā)計算機儲蓄系統(tǒng)，儲戶攜帶存折前去銀行辦理取款手續(xù)，他應把存折和填好的取款單一并交給銀行工作人員檢驗。工作人員需核對賬目，發(fā)現(xiàn)存折有效性問題、取款單填寫問題或是存折、賬卡與取款單不符等問題時均應報告儲戶。在檢驗通過的情形下，銀行則應將取款信息登記在存折和賬卡上，并通知付款。根據(jù)付款通知給儲戶付款。結(jié)構(gòu)化的需求分析與建模飛機機票預訂系統(tǒng)DFD圖下圖是一個飛機機票預訂系統(tǒng)的數(shù)據(jù)流圖，它反映的功能是：旅行社把預訂機票的旅客信息(姓名、年齡、單位、身份證號碼、旅行時間、目的地等)輸入機票預訂系統(tǒng)。系統(tǒng)為旅客安排航班，打印出取票通知單(附有應交的賬款)。旅客在飛機起飛的前一天憑取票通知單交款取票，系統(tǒng)檢驗無誤，輸出機票給旅客。結(jié)構(gòu)化的需求分析與建模畫數(shù)據(jù)流程圖的基本步驟①把一個系統(tǒng)看成一個整體功能，明確信息的輸入和輸出。②找到系統(tǒng)的外部實體。一旦找到外部實體，則系統(tǒng)與外部世界的界面就可以確定下來，系統(tǒng)的數(shù)據(jù)流的源點和終點也就找到了。③找出外部實體的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流。④在圖的邊上畫出系統(tǒng)的外部實體。結(jié)構(gòu)化的需求分析與建模畫數(shù)據(jù)流程圖的基本步驟⑤從外部實體的輸入流（源）出發(fā)，按照系統(tǒng)的邏輯需要，逐步畫出一系列邏輯處理過程，直至找到外部實體處理所需的輸出流，形成數(shù)據(jù)流的封閉。⑥將系統(tǒng)內(nèi)部數(shù)據(jù)處理又分別看做整體功能，其內(nèi)部又有信息的處理、傳遞、存儲過程。⑦如此一級一級地剖析，直到所有處理步驟都很具體為止。結(jié)構(gòu)化的需求分析與建模數(shù)據(jù)流圖的層次結(jié)構(gòu)

為了表達數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采用層次結(jié)構(gòu)的數(shù)據(jù)流圖。按照系統(tǒng)的層次結(jié)構(gòu)進行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關系，能清楚地表達和容易理解整個系統(tǒng)。結(jié)構(gòu)化的需求分析與建模分層的數(shù)據(jù)流圖數(shù)據(jù)流圖的層次結(jié)構(gòu)結(jié)構(gòu)化的需求分析與建模在多層數(shù)據(jù)流圖中，頂層流圖僅包含一個加工，它代表被開發(fā)系統(tǒng)。它的輸入流是該系統(tǒng)的輸入數(shù)據(jù)，輸出流是系統(tǒng)所輸出數(shù)據(jù)。底層流圖是指其加工不需再做分解的數(shù)據(jù)流圖，它處在最底層。中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續(xù)細化，形成子圖。數(shù)據(jù)流圖的層次結(jié)構(gòu)結(jié)構(gòu)化的需求分析與建模經(jīng)過初步的需求分析，得到系統(tǒng)功能要求：1、監(jiān)視病員的病癥（血壓、體溫、脈搏等）。2、定時更新病歷。3、病員出現(xiàn)異常情況時報警。4、隨機地產(chǎn)生某一病員的病情報告。醫(yī)院病房監(jiān)護系統(tǒng)產(chǎn)生病情報告監(jiān)視病情更新病歷結(jié)構(gòu)化的需求分析與建模系統(tǒng)功能要求：

1、監(jiān)視病員的病癥（血壓、體溫、脈搏等）

2、定時更新病歷

3、病員出現(xiàn)異常情況時報警。

4、隨機地產(chǎn)生某一病員的病情報告。頂層：病員護士護士病員監(jiān)護系統(tǒng)病員日志病癥信號要求報告病癥報告報警醫(yī)院病房監(jiān)護系統(tǒng)結(jié)構(gòu)化的需求分析與建模病員日志醫(yī)院病房監(jiān)護系統(tǒng)頂層DFD圖第一層：病員護士護士中央監(jiān)視病癥信號要求報告病癥報告報警局部監(jiān)視生成報告病員極限更新日志病員數(shù)據(jù)格式化病員數(shù)據(jù)生理信號極限值1324日志數(shù)據(jù)日志數(shù)據(jù)結(jié)構(gòu)化的需求分析與建模第二層：加工“中央監(jiān)視”分解計算超過極限值否病員數(shù)據(jù)超過極限值報警開解信號產(chǎn)生報警信息病員極限格式化病員數(shù)據(jù)體溫血壓、體溫脈搏生理信號極限值時間脈搏血壓日期時鐘格式化病員數(shù)據(jù)3.13.23.33.4醫(yī)院病房監(jiān)護系統(tǒng)二層DFD圖結(jié)構(gòu)化的需求分析與建模計算超過極限值否病員數(shù)據(jù)超過極限值報警開解信號產(chǎn)生報警信息病員極限格式化病員數(shù)據(jù)體溫血壓、體溫、脈搏生理信號極限值時間脈搏血壓日期時鐘格式化病員數(shù)據(jù)3.13.23.33.4第二層：加工“中央監(jiān)視”分解醫(yī)院病房監(jiān)護系統(tǒng)分層DFD圖第一層格式化病員數(shù)據(jù)生理信號極限值病員護士護士中央監(jiān)視病員日志病癥信號要求報告病癥報告報警局部監(jiān)視生成報告病員極限更新日志病員數(shù)據(jù)13