【正文】 檢查結果：分解不合適。 措施：刪去訂貨單數(shù)據(jù)流中的“貨號”成分。 17 父圖和子圖平衡嗎？從圖上看，子圖與父圖中相應加工并不具有相同的輸入和輸出，但是如果從詞典中查出：父圖只稱為“訂貨單”的數(shù)據(jù)流是由“客戶”、“帳號”和“數(shù)量”三部分數(shù)據(jù)組成的，那么就可得出結論：這兩張圖是平衡的 兩張數(shù)據(jù)流圖是平衡的，但是子圖中的文件 ALPHA 為什么在父圖中沒有畫出呢？這是因為 ALPHA 是完全局部于加工 的、它并不是父圖中各個加工之間的交界面，根據(jù)“抽象”原則，在畫父圖 時，只需畫出加工和加工之間的聯(lián)系，而不必畫出各個加工內部的細節(jié)，所以父圖中不必畫文件 ALPHA，同理，數(shù)據(jù)流 XXX、YYY 也不必畫出。 3) 如果發(fā)現(xiàn)難以為某個數(shù)據(jù)流命名，這往往是數(shù)據(jù)流圖分解不當?shù)恼髡?，此時可以試試重新分解是否能解決這個難題。 2) 子圖中加工的編號由子圖號、小數(shù)點、局部號連接而成。經過復審需求，學生不該購買或書已經賣完，則“無效書單“ 得到第二張圖 （ 2）在后面的分析建模中要將圖建模為 DFD圖（見后） 結構化分析模型描述工具 結構化分析模型 DFD、 DD和 PSPEC CFD、 CSPEC 和 STD ER 圖 面向對象分析模型（后續(xù)） 用例圖，對象 關系圖，對象 行為圖 有些數(shù)據(jù)加工不是數(shù)據(jù)觸發(fā)的，而是由實時發(fā)生的事件觸發(fā)的，無法用傳統(tǒng)的 DFD 圖來表示。 根據(jù)上述的功能描述，畫出分層數(shù)據(jù)流程圖。要求： 1）醫(yī)院對患者監(jiān)護系統(tǒng)的基本要求是隨時接收每個病人的生理信號 (脈搏，體溫，血壓，心電圖等 ) 2）定時記錄病人情況以形成患者日志 3）當某個病人的生理信號超出醫(yī)生規(guī)定的安全范圍時，向值班護士發(fā)出警告 4）護士在需 要時，還可以要求系統(tǒng)輸出某個指定病人的病情報告 某企業(yè)銷售管理系統(tǒng)的功能為： 1)接受顧客的訂單，檢驗訂單，若庫存有貨，進行供貨處理，即修改庫存，給倉庫開備貨單，并且將訂單留底；若庫存量不足，將缺貨訂單登入缺貨記錄。 是否考慮過將來可能會提出的軟件需求 。 主要功能是否已包括在規(guī)定的軟件范圍之內，是否都已充分說明 。 文檔中的所有描述是否完整、清晰、準確反映用戶要求 。 有異常，則在指定的延遲時間內撥報警電話號碼，撥號操作將按照重撥延遲反復進行，直至電話接通。這些異常事件應包括：非法進入、火災、水淹，等等。同時將 半小時數(shù)據(jù)供大屏幕顯示 為了使管理人員及時了解各班生產數(shù)據(jù)，通過班數(shù)據(jù)處理將半小時數(shù)據(jù)匯總成一個班的 8 小時數(shù)據(jù) 光電管 采集 計數(shù) 傳送 工控機 處理 實時數(shù)據(jù)顯示 班數(shù)據(jù) 處理 信號 半小時數(shù)據(jù) 班數(shù)據(jù) 半分鐘數(shù)據(jù) 只有數(shù)據(jù)流 事件發(fā)生的條件？ 事件或者控制信息發(fā)生后激活的那些加工？ 對于由事件驅動而不是數(shù)據(jù)驅動，產生的是控制信息而不單是數(shù)據(jù)流 以及必須依賴于時間的應用，只建立 DFD 是不夠的，還需要使用控制流圖建模。若有單科不及格 ,則發(fā)升級通知書 ,和重修通知書 若總分低于 600 分 ,若單科滿分 ,則發(fā)留級通知書 ,及免修單科通知書 。 ELSE 按書號檢索“教材存量表”，獲得書的單價和庫存量 IF 庫存量 購書單 .數(shù)量 THEN 把書號寫到出錯通知上 ELSE 將書號、單價、數(shù)量、總價等寫入發(fā)票 。 檢查結果：分解不合適。除了流向文件或從文件流出的數(shù)據(jù)流不必命名之外 (有文件名足矣 )， 返回 數(shù)據(jù)流圖中描述的是數(shù)據(jù)流而不是控制流。 STD 圖： Status Transfer Diagram 狀態(tài)－變遷圖 指明系統(tǒng)在外部事件的作用下將會如何動作，表明了系統(tǒng)的各種狀態(tài)間的變遷。CSPEC STD ER 圖 需求分析實例 軟件需求規(guī)格說明書 SRS 需求復審 軟件需求分析概述 需求分析的任務和步驟 需求獲取的常用方法 需求說明 分析建模模型 需求分析的任務 /步驟 (1)需求分析的任務 建立分析模型 編寫需求規(guī)格說明書 SRS(Software Requirement Specification) (2)需求分析的步驟 需求獲取 需求提煉 ：分析建模 需求描述 ：編寫 SRS 需求驗證 讓用戶和開發(fā)者共同明確將要開發(fā)的是什么樣的系統(tǒng) 目錄 簡單例－學生購書 張秘書開購書證明，學生憑證明到教材科王會計開購書發(fā)票向李出納員交納書款，拿領書單到書庫找保管員領書 B）去掉模型中非計算機本質的因素后得到的購書邏輯模型 人工操作，去掉 改進后的學生購買教材的系統(tǒng)模型 審查 并開發(fā)票 開領 書單 學 生 學 生 購書單 發(fā)票 領書單 無效書單 目錄 需求獲取的常用方法 收集資料 原有系統(tǒng)的數(shù)據(jù)（帳冊、報表。） 借鑒已有的類似軟件產品 聯(lián)合分析小組 用戶代表、領域專家和系統(tǒng)分析員 客戶訪談 amp。 目錄 結構化分析描述工具 功能模型： DFD 和 PSPEC 行為模型： CFD、 CSPEC 和 STD 數(shù)據(jù)模型： DD， ER圖 (1)數(shù)據(jù)流圖 DFD (2)數(shù)據(jù)字典 DD (3)加工說明 PSPEC (4) CFD 和 CSPEC (5)ER圖 (1)數(shù)據(jù)流圖 DFD 描述系統(tǒng)邏輯模型：信息在系統(tǒng)中的流動和處理 例 的 DFD 圖 數(shù)據(jù)源點和終點 加工 數(shù)據(jù)流向 數(shù)據(jù)文件或數(shù)據(jù)庫 數(shù)據(jù)流上的數(shù)據(jù)名稱 單向：只讀 雙向：讀寫 備注 文件與加工之間用箭頭線連接，單向表示只讀或只寫，雙向表示有讀有寫 每一圖形符號都必須標上名字 加工框還應加上編號 同程序流程圖的區(qū)別 程序流程圖表示程序的過程設計 —— 怎 么干 DFD 用是軟件需求分析工具，不表示程序的控制結構 (選擇 /循環(huán) )—— 干什么 分層 從高層到低層 分解前后的數(shù)據(jù)流必須一致 (一 )DFD 的繪制步驟 找出外部實體，確定系統(tǒng)邊界 從數(shù)據(jù)源出發(fā)，按系統(tǒng)的邏輯需求，逐步畫出加工框，直至數(shù)據(jù)終點 為了控