軟件的設計需求分析課件

1、需求分析福州大學 軟件學院張舒本章主要內容軟件需求分析的任務和過程 結構化分析方法 原型化方法 動態(tài)分析方法 數(shù)據(jù)及數(shù)據(jù)庫需求需求（Requirements)定義:需求是關于系統(tǒng)將要完成什么工作(what)的一段描述語句,是指用戶或者客戶對要開發(fā)的軟件系統(tǒng)的要求。它們必須經過所有相關人員的認可,其目的是徹底解決客戶的問題。需求的內容在“問題定義”中描述（可能是招標文件）。需求分析指開發(fā)人員為了準確地理解和表達用戶要求，進行細致的調查分析，將用戶非形式的需求陳述轉化為完整的需求定義，再由需求定義轉換到相應的形式功能規(guī)約（需求規(guī)格說明）的過程。準確地回答“系統(tǒng)必須做什么？”軟件需求分析的目標確定系

2、統(tǒng)的綜合要求確定系統(tǒng)功能、性能、運行等方面要求對將來可能提出的要求做準備分析系統(tǒng)的數(shù)據(jù)要求考慮數(shù)據(jù)、數(shù)據(jù)處理導出系統(tǒng)邏輯模型通常用數(shù)據(jù)流圖表示修正系統(tǒng)開發(fā)計劃對系統(tǒng)成本、進度有更精確的估算總之，需求分析的任務就是借助于當前系統(tǒng)的邏輯模型導出目標系統(tǒng)的邏輯模型，解決目標系統(tǒng)的 “做什么” 的問題。需求分析的重要性 “構建一個軟件系統(tǒng)最困難的部分是確定構建什么。其他部分工作不會像這部分工作一樣，在出錯之后會如此嚴重的影響隨后實現(xiàn)的系統(tǒng)，并且在以后修補竟會如此的困難?！?Fred Brooks 問題： 對于任何項目是否一定要嚴格執(zhí)行全面的需求分析呢？需求分析的過程(1) 問題識別確定對目標系統(tǒng)的綜合

3、要求，即軟件的需求提出這些需求實現(xiàn)條件，以及需求應達到的標準軟件的需求包括：功能需求性能需求環(huán)境需求可靠性需求安全保密要求用戶界面需求資源使用需求成本消耗需求開發(fā)進度需求預先估計以后系統(tǒng)可能達到的目標問題識別的另一項工作是建立分析所需要的通信途徑，以保證能順利地對問題進行分析。(2) 分析與綜合基本思想：從信息流和信息結構出發(fā)，逐步細化所有的軟件功能，找出系統(tǒng)各元素之間的聯(lián)系、接口特性和設計上的約束，分析它們是否滿足功能要求，是否合理。剔除其不合理的部分，增加其需要部分，最終綜合成系統(tǒng)的解決方案，給出目標系統(tǒng)的詳細邏輯模型。常用的分析方法功能分析法將系統(tǒng)看作若干功能模塊的集合，進行子功能分解，

4、最終形成系統(tǒng)雛形。結構化分析法面向數(shù)據(jù)流的結構化分析方法 (SA)面向數(shù)據(jù)結構的Jackson方法 (JSD)面向數(shù)據(jù)結構的結構化數(shù)據(jù)系統(tǒng)開發(fā)方法 (DSSD)常用的分析方法信息建模法借助各種有序模型（功能、信息、數(shù)據(jù)、控制、決策等），來分析系統(tǒng)。常用工具：ER圖面向對象的分析方法 (OOA) 識別問題域內對象，及其之間的聯(lián)系，并建立模型(3) 編制需求分析階段的文檔軟件需求說明書數(shù)據(jù)要求說明書初步的用戶手冊修改、完善與確定軟件開發(fā)實施計劃(4) 需求分析評審系統(tǒng)定義的目標是否與用戶的要求一致;系統(tǒng)需求分析階段提供的文檔資料是否齊全;文檔中的所有描述是否完整、清晰、準確反映用戶要求;與所有其它

5、系統(tǒng)成分的重要接口是否都已經描述;被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結構是否足夠確定;所有圖表是否清楚，在不補充說明時能否理解;主要功能是否已包括在規(guī)定的軟件范圍之內，是否都已充分說明;設計的約束條件或限制條件是否符合實際;開發(fā)的技術風險是什么;是否考慮過軟件需求的其它方案;是否考慮過將來可能會提出的軟件需求;是否詳細制定了檢驗標準，它們能否對系統(tǒng)定義是否成功進行確認;需求分析流程需求分析過程的任務可以概括為7個不同的活動：起始導出精化協(xié)商規(guī)格說明確認管理起始通常是在確定了商業(yè)要求或者發(fā)現(xiàn)新市場、新服務時，項目才開始，相關人員會進行粗略的可行性分析、并確定項目范圍后開始。導出需求看似簡單：詢問客戶，系統(tǒng)

6、或者產品的主要目標是什么？想要實現(xiàn)什么？產品如何滿足業(yè)務要求，如何用于日常工作？實則困難為何導出需求十分困難？范圍問題系統(tǒng)邊界不清楚，客戶或者用戶的說明帶有多余的技術細節(jié)，可能混淆系統(tǒng)整體目標理解問題用戶不能完全確定需要什么，在與工程師溝通過程中有問題。需求之間還可能存在沖突。易變問題需求隨時間變化可采取的解決辦法發(fā)掘需求克服企業(yè)背景對需求工程的影響克服方法不當對需求工程的影響。克服受訪談者對需求工程的影響。克服就項目論項目對需求工程的影響。 限制需求不能頭腦發(fā)熱認清真正的需求定義需求的邊界引導需求控制需求精化是一個分析建模動作，由一系列的建模和求精任務構成。最終形成一個分析模型，定義了問題的

7、信息域、功能域和行為域。 協(xié)商通過協(xié)商來調解需求沖突。規(guī)格說明可以是一份文檔、一套圖形化的模型等確認檢查規(guī)格說明，排除不一致性、疏漏和錯誤管理幫助項目組在進展中標識、控制和跟蹤需求及其變更軟件需求分析的原則需要能夠表達和理解問題的信息域和功能域要能以層次化的方式對問題進行分解和不斷細化要給出系統(tǒng)的邏輯視圖和物理視圖 信息域包括數(shù)據(jù)流、數(shù)據(jù)內容和數(shù)據(jù)結構。數(shù)據(jù)流就是數(shù)據(jù)經過系統(tǒng)時的變化形式，輸入數(shù)據(jù)先轉換成中間數(shù)據(jù)，再由中間數(shù)據(jù)轉換成輸出結果數(shù)據(jù)。數(shù)據(jù)內容就是數(shù)據(jù)項。數(shù)據(jù)結構就是各數(shù)據(jù)項的邏輯組織。 把問題以自頂向下、逐層分解的方式分解為幾個較易理解的部分，并確定各部分之間的接口，從而實現(xiàn)軟件的

8、整體功能。在需求分析階段，軟件的功能域和信息域都可以做進一步的分解。 邏輯視圖給出的是系統(tǒng)要達到的功能和要處理的信息間的關系，而不是實現(xiàn)細節(jié)。物理視圖給出的是系統(tǒng)處理功能和數(shù)據(jù)結構的實際表示形式，這通常由設備本身所決定。小結：需求分析方法實踐中，可以采取三階段分析法：第一階段：“訪談式”（Visitation）這一階段是和具體用戶方的領導層、業(yè)務層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現(xiàn)有的組織架構、業(yè)務流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運行系統(tǒng)等等具體情況、客觀的信息。 第二階段：“誘導式”（Inducement）在上一階段基礎上結合現(xiàn)有的硬件、軟件實現(xiàn)方案，做

9、出簡單的用戶流程頁面，同時結合以往的項目經驗對用戶采用誘導式、啟發(fā)式的調研方法和手段，和用戶一起探討業(yè)務流程設計的合理性、準確性、便易性、習慣性。用戶可以操作簡單演示的DEMO，來感受一下整個業(yè)務流程的設計合理性、準確性等等問題，及時地提出改進意見和方法。 第三階段：“確認式”（Afirm） 這一階段是在上述兩個階段成果的基礎上，進行具體的流程細化、數(shù)據(jù)項的確認階段，這個階段承建方必須提供原型系統(tǒng)和明確的業(yè)務流程報告、數(shù)據(jù)項表，并能清晰地向用戶描述系統(tǒng)的業(yè)務流設計目標。用戶方可以通過審查業(yè)務流程報告、數(shù)據(jù)項表以及操作承建方提供的DEMO系統(tǒng)，來提出反饋意見，并對已經可接受的報告、文檔簽字確認。

10、 軟件需求分析需求分析方法由對軟件問題的信息域和功能域的系統(tǒng)分析過程及其表示方法組成大多數(shù)的需求分析方法是由信息驅動的信息域具有三種屬性: 數(shù)據(jù)流、數(shù)據(jù)內容和數(shù)據(jù)結構。分析建模的方法20世紀70年代，人們從早期的、非結構化的方法入手，首次嘗試使用標準化的方法，開發(fā)并相繼推出了各種“結構化分析”方法，還相繼衍生出若干派生方法。20世紀90年代初，面向對象分析方法才悄然成形，并且同樣隨之出現(xiàn)了一批大同小異的派生方法。結構化分析 基本思想：用抽象模型的概念，按照軟件內部數(shù)據(jù)傳遞、變換的關系，自頂向下逐層分解，直到找到滿足功能要求的所有可實現(xiàn)的軟件為止。 結構化分析方法是一種依賴數(shù)據(jù)流圖的自頂向下的建

11、模方法，它的核心是數(shù)據(jù)流圖，所以又說它是一種面向數(shù)據(jù)流的分析方法。結構化分析方法適合于數(shù)據(jù)處理類型軟件的需求分析。結構化分析方法使用工具： 數(shù)據(jù)流圖 數(shù)據(jù)詞典 結構化英語 判定表與判定樹數(shù)據(jù)流圖數(shù)據(jù)流圖中的主要圖形元素數(shù)據(jù)加工 (數(shù)據(jù)變換)數(shù)據(jù)源點或終點 (外部實體)數(shù)據(jù)流數(shù)據(jù)存儲文件描述銀行取款過程的數(shù)據(jù)流圖數(shù)據(jù)流與數(shù)據(jù)加工之間的關系數(shù)據(jù)流圖的層次結構為了表達數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采用層次結構的數(shù)據(jù)流圖。按照系統(tǒng)的層次結構進行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結構關系，能清楚地表達和容易理解整個系統(tǒng)分層的數(shù)據(jù)流圖在多層數(shù)據(jù)流圖中，頂層流圖僅包含一個加工，它代表被開發(fā)系統(tǒng)。它的輸入

12、流是該系統(tǒng)的輸入數(shù)據(jù)，輸出流是系統(tǒng)所輸出數(shù)據(jù)底層流圖是指其加工不需再做分解的數(shù)據(jù)流圖，它處在最底層中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續(xù)細化，形成子圖。結構化分析方法步驟示例 商店業(yè)務處理系統(tǒng)數(shù)據(jù)流圖繪制步驟首先確定系統(tǒng)的輸入和輸出根據(jù)商店業(yè)務，畫出頂層數(shù)據(jù)流圖，以反映最主要業(yè)務處理流程這個數(shù)據(jù)流圖只是一個高層的系統(tǒng)邏輯模型，它反映了目標系統(tǒng)要實現(xiàn)的功能分析系統(tǒng)的主要功能：商店業(yè)務處理的主要功能應當有銷售、采購、會計三大項。主要數(shù)據(jù)流輸入的源點和輸出終點是顧客和供應商。然后從輸入端開始，根據(jù)商店業(yè)務工作流程，畫出數(shù)據(jù)流流經的各加工框，逐步畫到輸出端，得到第一層數(shù)據(jù)流圖第一層數(shù)

13、據(jù)流圖加細每一個加工框 銷售細化采購細化繪制數(shù)據(jù)流圖的原則數(shù)據(jù)流圖上所有圖形符號只限于前述四種基本圖形元素數(shù)據(jù)流圖的主圖必須包括前述四種基本元素，缺一不可數(shù)據(jù)流圖的主圖上的數(shù)據(jù)流必須封閉在外部實體之間每個加工至少有一個輸入數(shù)據(jù)流和一個輸出數(shù)據(jù)流在數(shù)據(jù)流圖中，需按層給加工框編號。編號表明該加工所處層次及上下層的親子關系規(guī)定任何一個數(shù)據(jù)流子圖必須與它上一層的一個加工對應，兩者的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流必須一致。此即父圖與子圖的平衡圖上每個元素都必須有名字數(shù)據(jù)流圖中不可夾帶控制流初畫時可以忽略瑣碎的細節(jié)，以集中精力于主要數(shù)據(jù)流如何分解加工？一個加工每次分解最多不要超過7個分解要自然，概念上要合理、清晰

14、在不影響數(shù)據(jù)流圖易理解性情況下，可以適當多分幾個部分上層可以分解得快些，中、下層要分解得慢些數(shù)據(jù)流圖的優(yōu)點自頂向下描述系統(tǒng)中信息的流動，結構清晰，概念性強，有利于系統(tǒng)分析員理順系統(tǒng)脈絡、澄清含混的概念和邏輯。數(shù)據(jù)流圖的表達方式是結構化的，易于與常用的計算機處理相對應，容易轉換為低級別的設計數(shù)據(jù)流圖的缺點可能變得非常復雜，不易理解。不能處理出錯和意外情況。不能描述過程的控制結構（沒有條件分支、循環(huán)、選擇）。數(shù)據(jù)詞典數(shù)據(jù)字典是為了描述在結構化分析過程中定義的對象的內容，而使用的一種半形式化的工具。數(shù)據(jù)字典是描述數(shù)據(jù)信息的集合，它對數(shù)據(jù)流圖中的各個元素進行完整的定義與說明，是數(shù)據(jù)流圖的補充工具。數(shù)據(jù)

15、字典的內容（1） 數(shù)據(jù)流在數(shù)據(jù)流圖中，數(shù)據(jù)以數(shù)據(jù)流為單位進行傳輸。主要描述該數(shù)據(jù)流的各組成部分，包括：名字及稱號?？赡艿膩碓春腿ヌ帲和獠繉嶓w，處理邏輯，數(shù)據(jù)存儲。組成：一個數(shù)據(jù)流可能包含若干個數(shù)據(jù)結構。例如，數(shù)據(jù)流“乘客名單”，由姓名、身份證、座位等級組成 乘客名單姓名身份證座位等級 （2）數(shù)據(jù)項數(shù)據(jù)項也稱數(shù)據(jù)元素，它“不可再分”，是數(shù)據(jù)的最小單位。主要給出每個數(shù)據(jù)單項的值類型、允許值，包括：名稱和編號。別名數(shù)據(jù)項另外的名稱。取值的范圍和含義。長度數(shù)據(jù)項包含的字符或數(shù)字的位數(shù)。例如：帳號=0000099999存款期限1|3|5 （3）文件條目主要給出文件的定義，通常列出組成文件記錄的數(shù)據(jù)流，包

16、括：名稱和編號。流入、流出數(shù)據(jù)流。流入數(shù)據(jù)流指出其來源，流出數(shù)據(jù)流指出其去向。組成，所包含的數(shù)據(jù)項和數(shù)據(jù)結構。例如：訂單文件訂單編號顧客名稱產品名稱訂貨數(shù)量交貨日期 （4）邏輯加工主要內容包括：名稱和編號。簡單描述。輸入輸出。主要功能。加工是DFD的重要組成部分，一般單獨進行說明。 （5）數(shù)據(jù)結構 數(shù)據(jù)結構是各個數(shù)據(jù)項之間的邏輯關系的一種描述。一個數(shù)據(jù)結構可以由若干個數(shù)據(jù)項組成，也可以由若干個數(shù)據(jù)項和數(shù)據(jù)結構組成。主要內容包括：名稱和編號組成。若是一個簡單的數(shù)據(jù)結構，需要列出它所包含的數(shù)據(jù)項；若是一個嵌套的數(shù)據(jù)結構，需要列出它所包含的數(shù)據(jù)結構名稱。數(shù)據(jù)結構的描述 符 號 含 義 舉 例 被定義

17、為 與 x = ab.,. 或 或 x = a , b .|. x = a | b . 或 m.n 重復 x = a，x = 3a8(.) 可選 x = (a)“.” 基本數(shù)據(jù)元素 x = “a” . 連結符 x = 1.9數(shù)據(jù)字典的用途數(shù)據(jù)字典中所建立的一組嚴密一致的定義有助于改進工程參與人員之間的通信，消除許多可能的誤會，避免許多麻煩的接口問題。數(shù)據(jù)字典列出了使用一個給定的數(shù)據(jù)元素的所有程序或模塊，很容易估計改變一個數(shù)據(jù)將產生的影響，并能對所有受影響的程序或模塊作出相應的改變。數(shù)據(jù)字典是開發(fā)數(shù)據(jù)庫的第一步。存折格式存折戶名所號帳號開戶日性質(印密)1存取行50戶名2字母24所號“001”.

18、“999” 帳號“00000001”.“99999999”開戶日年月日性質“1”.“6” 注：“1”表示普通戶，“5”表示工資戶等印密“0” 注：印密在存折上不顯示存取行日期（摘要）支出存入余額操作復核 對數(shù)據(jù)流圖的每一個基本加工，必須有一個基本加工邏輯說明基本加工邏輯說明必須描述基本加工如何把輸入數(shù)據(jù)流變換為輸出數(shù)據(jù)流的加工規(guī)則加工邏輯說明必須描述實現(xiàn)加工的策略而不是實現(xiàn)加工的細節(jié)加工邏輯說明中包含的信息應是充足的，完備的，有用的，無冗余的加工的邏輯說明用于寫加工邏輯說明的工具 結構化英語 判定表 判定樹（1）結構化英語結構化英語的詞匯表由 英語命令動詞 數(shù)據(jù)詞典中定義的名字 有限的自定義詞

19、 邏輯關系詞 IF_THEN_ELSE、 CASE_OF 、 WHILE_DO、 REPEAT_UNTIL等組成。是一種介于自然語言和形式化語言之間的語言,簡單、易學、少二義性。語言的正文用基本控制結構進行分割，加工中的操作用自然語言短語來表示。其基本控制結構有三種：簡單陳述句結構：避免復合語句。重復結構：while_do 或 repeat_until 結構。判定結構：if_then_else 或case_of 結構。商店業(yè)務處理系統(tǒng)中“檢查發(fā)貨單”if 發(fā)貨單金額超過$500 then if 欠款超過了60天 then 在償還欠款前不予批準 else （欠款未超期） 發(fā)批準書，發(fā)貨單 els

20、e （發(fā)貨單金額未超過$500） if 欠款超過60天 then 發(fā)批準書，發(fā)貨單及賒欠報告 else （欠款未超期） 發(fā)批準書，發(fā)貨單 （2）判定表如果數(shù)據(jù)流圖的加工需要依賴于多個邏輯條件的取值（組合條件），使用判定表來描述比較合適。一張判定表是一種二維表格，通常由四部分組成：左上部列出的是所有的條件，左下部為所有可能的操作，右上部分表示各種條件組合的一個矩陣，右下部分是對應于每種條件組合應有的操作。以“檢查發(fā)貨單”為例（3）判定樹判定樹也是用來表達加工邏輯的一種工具。有時侯它比判定表更直觀。檢查發(fā)貨單金額$500金額$500 欠款60天不發(fā)出批準書 欠款60天發(fā)貨單發(fā)出批準書、 欠款60天

21、發(fā)出批準書、發(fā)貨單及賒欠報告 欠款60天發(fā)出批準書、發(fā)貨單原型化方法在開發(fā)初期，要想得到一個完整準確的規(guī)格說明不是一件容易的事。特別是對一些大型的軟件項目。用戶往往對系統(tǒng)只有一個模糊的想法，很難完全準確地表達對系統(tǒng)的全面要求。軟件開發(fā)者對于所要解決的應用問題認識更是模糊不清隨著開發(fā)工作向前推進，用戶可能會產生新的要求，或因環(huán)境變化，要求系統(tǒng)也能隨之變化；開發(fā)者又可能在設計與實現(xiàn)的過程中遇到些沒有預料到的實際困難，需要以改變需求來解脫困境。 因此規(guī)格說明難以完善、需求的變更、以及通信中的模糊和誤解，都會成為軟件開發(fā)順利推進的障礙。為解決這些問題，逐漸形成了軟件系統(tǒng)的快速原型的概念。原型化方法基本

22、思想花費少量代價建立一個可運行的系統(tǒng)，使用戶及早獲得學習的機會，該方法又稱快速原型法。強調是軟件開發(fā)人員與用戶不斷交互，通過原型的演進不斷適應用戶任務改變的需求。軟件原型的分類廢棄（throw away）型：先構造一個功能簡單而且質量要求不高的模型系統(tǒng)，針對這個模型系統(tǒng)反復進行分析和修改，從而形成比較好的設計思想，據(jù)此設計出更加完整、準確、一致、可靠的最終系統(tǒng)。系統(tǒng)構造完成后，原來的模型系統(tǒng)就被廢棄不用。追加（add on）型：先構造個功能簡單而且質量要求不高的模型系統(tǒng)，作為最終系統(tǒng)的核心，然后通過不斷地擴充、修改、逐步追加新需求，最后發(fā)展成為最終系統(tǒng)。建立快速原型，進行系統(tǒng)的分析和構造的好處

23、： 增進軟件者和用戶對系統(tǒng)服務需求的理解，使比較含糊的具有不確定性的軟件需求（主要是功能）明確化。 軟件原型化方法提供了一種有力的學習手段。 使用原型化方法，可以容易地確定系統(tǒng)的功能，確認各項主要系統(tǒng)服務的可應用性，確認系統(tǒng)設計的可行性，確認系統(tǒng)作為產品的結果。 軟件原型的最終版本，有的可以原封不動地成為產品，有的略加修改就可以成為最終系統(tǒng)的一個組成部分，這樣有利于建成最終系統(tǒng)。 系統(tǒng)動態(tài)分析一個軟件系統(tǒng)在其運行的過程中，構成系統(tǒng)的各個元素狀態(tài)都在改變。為了直觀地分析系統(tǒng)的動作，從特定的視點出發(fā)描述系統(tǒng)的行為，需要采用動態(tài)分析的方法。最常用的動態(tài)分析方法狀態(tài)遷移圖時序圖Petri網(wǎng)狀態(tài)遷移圖狀

24、態(tài)遷移圖是描述系統(tǒng)的狀態(tài)如何相應外部的信號進行推移的一種圖形表示。 圓圈“”表示可得到的系統(tǒng)狀態(tài) 箭頭“”表示從一種狀態(tài)向另一種狀態(tài)的遷移。例如, 當有多個申請占用CPU運行的進程時, 有關CPU分配的進程的狀態(tài)遷移。可得到的狀態(tài)就緒，運行，等待生成的事件t1，t2， t3， t4 t1 中斷事件 t2 中斷已處理 t3 分配CPU t4 用完CPU時間狀態(tài)遷移圖的優(yōu)點狀態(tài)之間的關系能夠直觀地捕捉到。由于狀態(tài)遷移圖的單純性，能夠機械地分析許多情況，可很容易地建立分析工具在系統(tǒng)分析中，用時序圖來對比在系統(tǒng)中處理事件的時序和相應的處理時間。時序圖 在下圖中, 對于事件e, 功能1功能3的處理時間總

25、計為 (T1T2T3）其中功能間切換時間0。 采用擴充時序圖可表示進程間的通信流,用于分析幾個事件的交錯現(xiàn)象。C1與C2，R1與R2是交錯的。因此，可以做如下分析：“必須設計成HOST1 在等待C1的回答R1期間要能接收從HOST2發(fā)出的命令C2?！盤etri網(wǎng) Petri網(wǎng)已廣泛地應用于硬件與軟件系統(tǒng)的開發(fā)中，它適用于描述與分析相互獨立、協(xié)同操作的處理系統(tǒng)，也就是并發(fā)執(zhí)行的處理系統(tǒng)。Petri網(wǎng)簡稱PNG (Petri Net Graph)，是一種有向圖，它有兩種結點：位置(place)：符號為“”，它用來表示系統(tǒng)的狀態(tài)。轉移(transition)：符號為 “”或“|”, 它用來表示系統(tǒng)中

26、的事件。 圖中的有向邊表示對轉移的輸入，或由轉移的輸出標記，或稱令牌(token)，是表明系統(tǒng)當前處于什么狀態(tài)的標志 處理兩個進程的同步問題數(shù)據(jù)及數(shù)據(jù)庫需求在數(shù)據(jù)詞典中，強調對數(shù)據(jù)存儲結構的邏輯設計，并用數(shù)據(jù)結構表達數(shù)據(jù)項之間的邏輯關系。但任何一個軟件系統(tǒng)都可能有成千上萬個數(shù)據(jù)項，僅僅描述這些數(shù)據(jù)項是不夠的，更重要的是如何把它們以最優(yōu)的方式組織起來，以滿足系統(tǒng)對數(shù)據(jù)的要求。E-R方法 ( Entity-Relationship Approach) 和實體模型在需求分析階段進行數(shù)據(jù)庫邏輯設計過程中，使用E-R圖，可定義一個實體模型。實體模型是現(xiàn)實世界的純表示，它不涉及數(shù)據(jù)世界的數(shù)據(jù)結構、存取路徑

27、、存取效率等問題。因此，它可以轉換成數(shù)據(jù)庫中的數(shù)據(jù)模型。在E-R圖中，每個方框表示實體型或屬性，方框之間的連線表示實體之間，或實體與屬性之間的聯(lián)系。出現(xiàn)在連線上的短豎線可以看成是“1”，而圓圈隱含表示“0”。例如，在教學管理中，一個教師可以教授零門、一門或多門課程，每位學生也需要學習幾門課程。因此，教學管理中涉及的對象（實體型）有學生、教師和課程。進一步，要確定屬性。例如，學生具有學號、姓名、性別、年齡、專業(yè)（其它略）等屬性；課程具有課程號、課程名、學分、學時數(shù)等屬性；教師具有職工號、姓名、年齡、職稱等屬性。此外，學生通過學號、分數(shù)與課程發(fā)生聯(lián)系。如此可得教學實體模型。數(shù)據(jù)庫分析的過程在需求分

28、析階段進行數(shù)據(jù)庫分析的流程為開發(fā)一個系統(tǒng)所使用的數(shù)據(jù)庫，在開始分析數(shù)據(jù)庫的需求前，分析員必須了解該系統(tǒng)的總目標和范圍。然后建立一個完整并高度細化的信息模型。此信息模型應包括一個綜合的數(shù)據(jù)詞典，定義所有在開發(fā)數(shù)據(jù)庫時用到的數(shù)據(jù)項。接著數(shù)據(jù)庫分析定義數(shù)據(jù)庫的邏輯特性和物理特性。以信息模型和系統(tǒng)規(guī)格說明為指導，定義數(shù)據(jù)庫的邏輯數(shù)據(jù)結構。這種邏輯結構必須適應數(shù)據(jù)存取、修改、關聯(lián)性及其它相關需求。一旦邏輯數(shù)據(jù)結構建立起來，就可以研制數(shù)據(jù)庫的物理結構。物理數(shù)據(jù)庫結構定義文件結構、記錄格式、與硬件相關的處理方式以及數(shù)據(jù)庫管理系統(tǒng)的特性。最后，要對模式和物理特性進行完全的評審。需求規(guī)格說明書軟件需求規(guī)格說明是

29、分析任務的最終產物。需求規(guī)格說明書的主要作用：（1）軟件開發(fā)機構和用戶之間一份事實上的技術合同書。（2）軟件開發(fā)機構下一步進行設計和編碼的基礎。（3）測試和驗收目標系統(tǒng)的依據(jù)。軟件需求規(guī)格說明的原則從現(xiàn)實中分離功能，即描述要“做什么”而不是“怎樣實現(xiàn)”要求使用面向處理的規(guī)格說明語言（或稱系統(tǒng)定義語言）如果被開發(fā)軟件只是一個大系統(tǒng)中的一個元素，那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中規(guī)格說明必須包括系統(tǒng)運行環(huán)境規(guī)格說明必須是一個認識模型規(guī)格說明必須是可操作的規(guī)格說明必須容許不完備性并允許擴充規(guī)格說明必須局部化和松散耦合需求規(guī)格說明內容框架參見國標文檔：GB856T88結構化分析小結結構化分析是一

30、種有相當長歷史的分析方法，依據(jù)軟件內部的數(shù)據(jù)傳遞、變換關系、自頂向下逐層分解，描繪出滿足功能要求的軟件模型。該分析方法給出一組幫助系統(tǒng)分析人員產生功能規(guī)約的原理與技術。它一般利用圖形表達用戶需求，使用的手段主要有數(shù)據(jù)流圖、數(shù)據(jù)字典、結構化語言、判定表以及判定樹等。 著眼于軟件系統(tǒng)需要什么樣的方法和處理過程，以過程抽象來對待系統(tǒng)的需求，其主要思想就是對問題進行功能分解，因此結構化方法也叫功能分解法?，F(xiàn)實世界被影射為功能的集合。結構化分析的步驟 分析當前的情況，做出反映當前物理模型的DFD；推導出等價的邏輯模型的DFD；設計新的邏輯系統(tǒng)，生成數(shù)據(jù)字典和基元描述；建立人機接口，提出可供選擇的目標系統(tǒng)

31、物理模型的DFD；確定各種方案的成本和風險等級，據(jù)此對各種方案進行分析；選擇一種方案；建立完整的需求規(guī)約。 結構化分析的不足關注的是數(shù)據(jù)和流程，這些易變化的項目，因此受需求變更的影響很大。面向對象分析 面向對象方法著眼于問題域中事物，以數(shù)據(jù)抽象來實現(xiàn)系統(tǒng)的需求?，F(xiàn)實世界中的實體及其相互關系被影射為對象及對象間的關系，實體之間的相互作用被影射為對象間的消息發(fā)送，以及其它類似的各種影射關系。UML簡介UML是由著名的面向對象技術專家 Grady Booch（布什）、James Rumbaugh（云豹）和Ivar Jacobson（雅 森），在各自方法的基礎上，汲取其他面向對象方法的優(yōu)點，廣泛征求意

32、見，幾經修改完成的一種建模語言。uml構成 基本構造塊basic building block事物thing結構事物（structural thing）行為事物（behavioral thing）分組事物（grouping thing）注釋事物（annotational thing）關系relationship圖diagram規(guī)則rule通用機制common mechanism行為事物：交互（interaction）和狀態(tài)機（state machine）結構事物：類、接口、協(xié)作、用例、主動類、組件和結點分組事物：包（package）注釋事物：注解（note） 基本構造塊basic building block事物thing關系relationship圖diagram依賴（dependency）關聯(lián)（association）泛化（generalization）實現(xiàn)（realization）規(guī)則rule通用機制common mechanism關聯(lián)：兩個類存在結構上的關系，如一個公司有許多員工，公司與員工之間具有關聯(lián)關系。依賴：如，A類的方法使用了B類對象（作為參數(shù)），則A類依賴B類。泛化：定義了一般元