【正文】 入數(shù)據(jù)和輸出數(shù)據(jù)應(yīng)該保持一致 例 局部文件隱蔽與文件是否具有讀寫加工 分解的速度不要太快 每次加工分解一次最多 =7 應(yīng)遵守加工編號規(guī)則 頂層無圖號 第 0 層 圖 0： 1， 2， 3， 第 1 層 圖 1： ， , .. ， ， .. 數(shù)據(jù)守恒 DFD 各個加工之間的數(shù)據(jù)流應(yīng)盡可能少 —— 否則重新分解 DFD 1 銷售 2 采購 書庫 保管員 學(xué) 生 購書單 進書通知 F1 教材存量表 F2 缺書登記表 缺書單 進書通知 領(lǐng)書單 發(fā)票 In：購書單，進書通知 Out：發(fā)票，領(lǐng)書單 實例 2：家庭保安 系統(tǒng) 背景 家庭保安市場正以每年 40％的速度增長。這些異常事件應(yīng)包括：非法進入、火災(zāi)、水淹，等等。此外，系統(tǒng)應(yīng)允許戶主對其行為實施程序式控制。 有異常，則在指定的延遲時間內(nèi)撥報警電話號碼，撥號操作將按照重?fù)苎舆t反復(fù)進行，直至電話接通。 (1)家庭保安系統(tǒng)的頂級 DFD (2)家庭保安系統(tǒng)的第 1級 DFD 傳感器監(jiān)測第 1級 DFD (3)傳感器監(jiān)測子系統(tǒng)第 2級 DFD (4)傳感器監(jiān)測子系統(tǒng)第 3級 DFD 軟件需求說明書 SRS IEEE8301998 和我國國家標(biāo)準(zhǔn) GB856788 1 引言 (1) 編寫目的 (2) 范圍 (3) 定義 (4) 參考資料 2 項目概述 (1)產(chǎn)品描述 (2) 產(chǎn)品功能 (3) 用戶特點 (4) 一般約束 (5) 假設(shè)和依據(jù) 3 具體需求 功能需求 (1) 功能需求 1 ? (N) 功能需求 n 外部接 口需求 (1) 用戶接口 (2) 硬件接口 (3) 軟件接口 (4) 通信接口 性能需求 (1)數(shù)據(jù)精確度 (2)時間特性 (3)適應(yīng)性 設(shè)計約束 (1) 其他標(biāo)準(zhǔn)的約束 (2) 硬件的限制 屬性 (1) 可用性 (2) 安全性 (3) 可維護性 (4) 可轉(zhuǎn)移 / 轉(zhuǎn)換性 (5) 警告 其他需求 (1) 數(shù)據(jù)庫 (2) 操作 (3) 場合適應(yīng)性 4 附錄 需求分析 評審 系統(tǒng)定義的目標(biāo)是否與用戶的要求一致 。 文檔中的所有描述是否完整、清晰、準(zhǔn)確反映用戶要求 。 被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠，確定 。 主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)，是否都已充分說明 。 開發(fā)的技術(shù)風(fēng)險是什么 。 是否考慮過將來可能會提出的軟件需求 。 作業(yè) 0層數(shù)據(jù)流圖 “病員監(jiān)視系統(tǒng)”的數(shù)據(jù)流圖 目前住院病人主要由護士到病房和病床前逐個護理，不僅需要大量的護士，而且由于不能隨時觀察危重病人的病情變化，還會延誤搶救時機。要求： 1）醫(yī)院對患者監(jiān)護系統(tǒng)的基本要求是隨時接收每個病人的生理信號 (脈搏，體溫，血壓，心電圖等 ) 2）定時記錄病人情況以形成患者日志 3）當(dāng)某個病人的生理信號超出醫(yī)生規(guī)定的安全范圍時，向值班護士發(fā)出警告 4）護士在需 要時，還可以要求系統(tǒng)輸出某個指定病人的病情報告 某企業(yè)銷售管理系統(tǒng)的功能為： 1)接受顧客的訂單，檢驗訂單，若庫存有貨，進行供貨處理，即修改庫存，給倉庫開備貨單，并且將訂單留底；若庫存量不足，將缺貨訂單登入缺貨記錄。 3)根據(jù)采購部門發(fā)來的進貨通知單處理進貨，并修改庫存，并從缺貨記錄中取出缺貨訂單進行供貨處理。 根據(jù)上述的功能描述，畫出分層數(shù)據(jù)流程圖。人是可能變動的，但是他們的工作崗位是不變的，歸結(jié)為審查、開發(fā)票、開書單、發(fā)書 2。經(jīng)過復(fù)審需求，學(xué)生不該購買或書已經(jīng)賣完，則“無效書單“ 得到第二張圖 （ 2）在后面的分析建模中要將圖建模為 DFD圖（見后） 結(jié)構(gòu)化分析模型描述工具 結(jié)構(gòu)化分析模型 DFD、 DD和 PSPEC CFD、 CSPEC 和 STD ER 圖 面向?qū)ο蠓治瞿Ｐ停ê罄m(xù)） 用例圖，對象 關(guān)系圖，對象 行為圖 有些數(shù)據(jù)加工不是數(shù)據(jù)觸發(fā)的，而是由實時發(fā)生的事件觸發(fā)的，無法用傳統(tǒng)的 DFD 圖來表示。 頂層圖被稱為是圖 0 的“父圖” , 圖 0 稱為是頂層圖的“子圖”；同樣，圖0是 圖 l、圖 2和圖 3 的“父圖”，圖 l、圖 2 和圖 3是圖 0 的“子圖”。 2) 子圖中加工的編號由子圖號、小數(shù)點、局部號連接而成。有了這樣的規(guī)則，只要數(shù)一下子圖編號的小數(shù)點數(shù)，就可知道這張于圖位于哪一層，另外，根據(jù)編號就可知道某一張圖的父圖是哪一張 。 3) 如果發(fā)現(xiàn)難以為某個數(shù)據(jù)流命名，這往往是數(shù)據(jù)流圖分解不當(dāng)?shù)恼髡?，此時可以試試重新分解是否能解決這個難題。 16 父圖和子圖是不 平衡的，因為子圖中沒有輸入數(shù)據(jù)流與父圖中加工2的輸入流 M 相對應(yīng)。 17 父圖和子圖平衡嗎？從圖上看，子圖與父圖中相應(yīng)加工并不具有相同的輸入和輸出，但是如果從詞典中查出：父圖只稱為“訂貨單”的數(shù)據(jù)流是由“客戶”、“帳號”和“數(shù)量”三部分?jǐn)?shù)據(jù)組成的，那么就可得出結(jié)論：這兩張圖是平衡的 兩張數(shù)據(jù)流圖是平衡的，但是子圖中的文件 ALPHA 為什么在父圖中沒有畫出呢？這是因為 ALPHA 是完全局部于加工 的、它并不是父圖中各個加工之間的交界面，根據(jù)“抽象”原則，在畫父圖 時，只需畫出加工和加工之間的聯(lián)系，而不必畫出各個加工內(nèi)部的細(xì)節(jié)，所以父圖中不必畫文件 ALPHA，同理，數(shù)據(jù)流 XXX、YYY 也不必畫出。 措施：補上相應(yīng)數(shù)據(jù)流。 措施：刪去訂貨單數(shù)據(jù)流中的“貨號”成分。 應(yīng)減少數(shù)據(jù)流圖中加工間的數(shù)據(jù)流 ，使各個加工相對獨立。 檢查結(jié)果：分解不合適。 數(shù)據(jù)詞典與數(shù)據(jù)流圖配合，能清楚 地表達(dá)數(shù)據(jù)處理的要求 詞條描述 —— 對于在數(shù)據(jù)流圖中每一個被命名的圖形元素，均加以定義，其內(nèi)容有 :名字，別名或編號，分類，描述，定義，位置，其它，等 ：見后 P4243, 例 演示是動畫的，但實際的圖是靜態(tài)的， 那么如何表示狀態(tài)的變遷？系統(tǒng)的 行為？ — STD