【正文】 軟件系統(tǒng)結(jié)構(gòu)中各模塊間相互聯(lián)系緊密程度的一種度量 。 73 （ 2） 概要設(shè)計(jì)的基本原理 4)模塊獨(dú)立性 模塊獨(dú)立性是指每個(gè)模塊只完成系統(tǒng)要求的獨(dú)立的子功能 ， 并且與其他模塊的聯(lián)系最少且接口簡(jiǎn)單 。 72 （ 2） 概要設(shè)計(jì)的基本原理 3) 抽象信息隱藏 信息隱藏 指在設(shè)計(jì)和確定模塊時(shí) ， 使得一個(gè)模塊內(nèi)包含的信息 （ 過(guò)程或數(shù)據(jù) ） ， 對(duì)于不需要這些信息的其他模塊來(lái)說(shuō) ， 是不能訪問(wèn)的 。 模塊化 是指解決一個(gè)復(fù)雜問(wèn)題時(shí)自頂向下逐層把軟件系統(tǒng)劃分成若干模塊的過(guò)程 。 d. 修訂測(cè)試計(jì)劃 ， 對(duì)測(cè)試策略 、 方法 、 步驟提出明確要求 。 b. 對(duì)數(shù)據(jù)庫(kù)的設(shè)計(jì)是指數(shù)據(jù)存儲(chǔ)文件的設(shè)計(jì) ，主要進(jìn)行概念設(shè)計(jì) 、 邏輯設(shè)計(jì) 、 物理設(shè)計(jì)三方面設(shè)計(jì) 。 d. 確定模塊之間的接口 ， 即模塊之間傳遞的信息 。 主要確定每個(gè)模塊的具體執(zhí)行過(guò)程，也稱為過(guò)程設(shè)計(jì)。 對(duì)數(shù)據(jù)流圖中出現(xiàn)的每一個(gè)數(shù)據(jù)流、文件、加工給出詳細(xì)定義。 52 ? 是一種介于自然語(yǔ)言和形式化語(yǔ)言之間的語(yǔ)言 ? 語(yǔ)言的 正文用基本控制結(jié)構(gòu)進(jìn)行分割 ，加工中的 操作用自然語(yǔ)言短語(yǔ)來(lái)表示 ? 其基本控制結(jié)構(gòu)有三種： ?簡(jiǎn)單陳述句結(jié)構(gòu) ： 避免復(fù)合語(yǔ)句； ?重復(fù)結(jié)構(gòu) ： while_do 或 repeat_until 結(jié)構(gòu)。 SA是一種建模活動(dòng) ， 該方法使用簡(jiǎn)單易讀符號(hào) ， 根據(jù) 軟件內(nèi)部數(shù)據(jù)傳遞 、 變換的關(guān)系 ， 自頂向下逐層分解 ， 描繪出滿足功能需求的軟件模型 。 包括：對(duì)數(shù)據(jù)域進(jìn)行分解，并分配到各個(gè)子功能上，以確定系統(tǒng)的構(gòu)成及主要成分，并用圖文結(jié)合的形式，建立起新系統(tǒng)的邏輯模型。 包括：功能需求、性能需求、環(huán)境需求和用戶界面需求。 37 二、 軟件系統(tǒng)需求分析 1. 需求分析概念 2. 需求分析的基本任務(wù) 3. 結(jié)構(gòu)化分析方法 BDS 38 數(shù)據(jù)庫(kù)建設(shè)的基本規(guī)律 三分 技術(shù)， 七分 管理， 十二分 基礎(chǔ)數(shù)據(jù) 管理 ?數(shù)據(jù)庫(kù)建設(shè)項(xiàng)目管理 ?企業(yè)（即應(yīng)用部門）的業(yè)務(wù)管理 基礎(chǔ)數(shù)據(jù) ?收集、入庫(kù) ?更新新的數(shù)據(jù) 39 二、 軟件系統(tǒng)需求分析 1. 需求分析概念 2. 需求分析的基本任務(wù) 3. 結(jié)構(gòu)化分析方法 40 需求的定義 ? IEEE Standard Glossary of Software Engineering Terminology ?用戶解決一個(gè)問(wèn)題或達(dá)到一個(gè)目標(biāo)所需要的一種狀況或能力 ?系統(tǒng)為了滿足一種約定、標(biāo)準(zhǔn)、規(guī)格說(shuō)明或其它正式文件而必須滿足或擁有的一種狀況或能力 ?以上兩種狀態(tài)或能力的文檔化表示 主觀需求 客觀需求 需求文檔 41 功能性需求和非功能性需求 ? 功能性需求 ?系統(tǒng)需要提供的服務(wù)或功能：如圖書(shū)檢索 ?系統(tǒng)對(duì)特定輸入的處理方式：如對(duì)非法輸入的提示 ?系統(tǒng)在特定環(huán)境下的行為：如長(zhǎng)時(shí)間無(wú)操作時(shí)的屏保 ? 非功能性需求 ?對(duì)系統(tǒng)功能或服務(wù)附加的質(zhì)量約束，例如響應(yīng)時(shí)間、容錯(cuò)性、安全性等 —— 客戶所關(guān)心的 (外部質(zhì)量 ) ?從系統(tǒng)開(kāi)發(fā)和維護(hù)角度出發(fā)的質(zhì)量屬性，例如可理解性、可擴(kuò)展性、可配置性等 —— 軟件開(kāi)發(fā)或維護(hù)者所關(guān)心的 (內(nèi)部質(zhì)量、軟件所特有 ) 42 二、 軟件系統(tǒng)需求分析 是指開(kāi)發(fā)人員要準(zhǔn)確理解用戶的要求 ， 進(jìn)行細(xì)致的調(diào)查分析 ， 將用戶非形式的需求陳述轉(zhuǎn)化為完整的需求定義 ， 再由需求定義轉(zhuǎn)換到相應(yīng)的形式功能規(guī)約 （ 需求規(guī)格說(shuō)明 ） 的過(guò)程 。 5． 所建議系統(tǒng)的經(jīng)濟(jì)可行性分析 。 niFP )1/( ?? niPF )1( ??31 ? 投資回收期 ： 累計(jì)的經(jīng)濟(jì)效益正好等于投資數(shù)（成本）所需的時(shí)間 ? 純收入 ：累計(jì)經(jīng)濟(jì)效益 – 投資數(shù) ? 當(dāng)純收入大于零時(shí)，該工程值得投資開(kāi)發(fā) ? 當(dāng)純收入小于零時(shí)，該工程不值得投資（除非它有明顯的社會(huì)效益） ? 當(dāng)純收入等于零時(shí)，通常也不值得投資 顯然，純收入越大越好 32 軟件可行性研究 3． 社會(huì)可行性 要開(kāi)發(fā)的項(xiàng)目是否存在任何侵犯 、 妨礙等責(zé)任問(wèn)題 ? 要開(kāi)發(fā)項(xiàng)目的運(yùn)行方式在用戶組織內(nèi)是否行得通 ? 現(xiàn)有管理制度 、 人員素質(zhì) 、 操作方式是否可行 ? ? 三個(gè)方面的可行性 33 中華人民共和國(guó)著作權(quán)法 計(jì)算機(jī)軟件保護(hù)條例 保密法 等 34 可行性分析的結(jié)論 ? 可以立即開(kāi)始進(jìn)行 ? 需要推遲到某些條件 （ 例如資金 、 人力 、 設(shè)備等 ）落實(shí)之后才能開(kāi)始進(jìn)行 ? 需要對(duì)開(kāi)發(fā)目標(biāo)進(jìn)行某些修改之后才能開(kāi)始進(jìn)行 ? 因?yàn)槟撤N原因 （ 如 ， 技術(shù)不成熟 、 經(jīng)濟(jì)上不合算等） 不能進(jìn)行 35 軟件可行性研究 1． 復(fù)查項(xiàng)目規(guī)模和目標(biāo) 2． 研究正在使用的系統(tǒng) 3． 得到新系統(tǒng)的概括的邏輯模型 4． 導(dǎo)出和評(píng)價(jià)各種方案 5． 推薦可行的方案 6． 編寫可行性研究報(bào)告 ? 可行性研究的具體步驟 36 軟件可行性研究 ? 可行性研究報(bào)告內(nèi)容 1． 引言 。 ?社會(huì)效益 ?使用基于計(jì)算機(jī)的系統(tǒng)后對(duì)社會(huì)產(chǎn)生的影響（如提高了辦事效益，使用戶滿意等），通常社會(huì)效益只能定性地估計(jì)。 例如，有一支開(kāi)發(fā)過(guò)類似項(xiàng)目的開(kāi)發(fā)和管理的團(tuán)隊(duì)，或者開(kāi)發(fā)人員比較熟悉系統(tǒng)所處的領(lǐng)域，并有足夠的人員保證，所需的硬件和支撐軟件能通過(guò)合法的手段獲取，那么從技術(shù)角度看，可以認(rèn)為具備設(shè)計(jì)和實(shí)現(xiàn)系統(tǒng)的條件。 資源：已有的或可以獲得的硬件 、 軟件資源 現(xiàn)有技術(shù)人員的技術(shù)水平 已有的工作基礎(chǔ) 。 分析員進(jìn)行簡(jiǎn)要的需求分析 ， 抽象出邏輯結(jié)構(gòu) ， 建立邏輯模型 。是指從形成開(kāi)發(fā)軟件概念起 ， 所開(kāi)發(fā)的軟件使用以后 ， 直到失去使用價(jià)值消亡為止的整個(gè)過(guò)程 。如軟件開(kāi)發(fā)工具、測(cè)試工具等。 14 軟件工程的 目標(biāo) ? 能按時(shí)完成開(kāi)發(fā)任務(wù) ， 及時(shí)交付使用； ? 付出較低的開(kāi)發(fā)成本 ， 達(dá)到要求的軟件功能； ? 取得較好的軟件性能； ? 開(kāi)發(fā)的軟件易于移植； ? 需要較低的維護(hù)費(fèi)用； ? 開(kāi)發(fā)的軟件可靠性高 。最后無(wú)法逃脫滅頂?shù)臑?zāi)難?？岂R洛夫 8 軟件工程相關(guān)概念 ? 軟件危機(jī) : 危機(jī)實(shí)例（ 3）： 人員傷亡：由于計(jì)算機(jī)軟件被廣泛應(yīng)用于包括醫(yī)院等與生命息息相關(guān)的行業(yè)。 6 軟件發(fā)展的三個(gè)階段 ?程序設(shè)計(jì)時(shí)代（ 5060年代） 軟件指程序，軟件開(kāi)發(fā)關(guān)注程序編寫，用匯編及機(jī)器語(yǔ)言 ?程序系統(tǒng)時(shí)代（ 6070年代） 軟件指程序及說(shuō)明書(shū)，軟件開(kāi)發(fā)包括程序設(shè)計(jì)和測(cè)試，用高級(jí)語(yǔ)言 ?軟件工程時(shí)代（ 70年代以后） 軟件開(kāi)發(fā)包括軟件生命期，用軟件語(yǔ)言（包括需求定義語(yǔ)言、軟件功能語(yǔ)言、軟件設(shè)計(jì)語(yǔ)言、程序設(shè)計(jì)語(yǔ)言等） 7 軟件工程相關(guān)概念 ? 軟件危機(jī) : 在軟件開(kāi)發(fā)過(guò)程中遇到的問(wèn)題找不到解決的辦法，致使問(wèn)題積累起來(lái)形成了日益尖銳的矛盾。 ?一次性 — 創(chuàng)造性的產(chǎn)物。程序必須裝入計(jì)算機(jī)內(nèi)才能工作 ?文檔是為了便于了解程序所需的 闡明性 資料，文檔一般是給人看的，不一定裝入計(jì)算機(jī) 4 5 軟件的特點(diǎn)： ?抽象性 — 不是實(shí)物。 ?嚴(yán)密性 — 是邏輯產(chǎn)品。 ?難以度量 — 難定量測(cè)量。 危機(jī)實(shí)例（ 1）： 1963年美國(guó)飛往火星的火箭探測(cè)器爆炸，造成 1000萬(wàn)美元 (數(shù)億美元 )的損失。這也使得軟件的錯(cuò)誤導(dǎo)致人員傷亡成為了可能。程序設(shè)計(jì)工作正像這樣一個(gè)泥潭，一批批程序員被迫在泥潭中拼命掙扎， …… 誰(shuí)也沒(méi)料到問(wèn)題竟會(huì)陷入這樣的困境 ……” 10 軟件危機(jī)的表現(xiàn) ? 對(duì)軟件開(kāi)發(fā)成本和進(jìn)度的估計(jì)常常很不正確 ? 用戶對(duì)“已完成的”軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生 ? 軟件產(chǎn)品的質(zhì)量往往靠不住 ? 軟件常常是不可維護(hù)的 ? 軟件通常沒(méi)有適當(dāng)?shù)奈臋n資料 ? 軟件成本在計(jì)算機(jī)系統(tǒng)總成本中所占的比例逐年上升 ? 軟件開(kāi)發(fā)生產(chǎn)率提高的速度遠(yuǎn)遠(yuǎn)跟不上計(jì)算機(jī)應(yīng)用迅速普及深入的趨勢(shì) 11 軟件危機(jī)的原因 ? 軟件是邏輯產(chǎn)品，開(kāi)發(fā)進(jìn)度、成本難以估計(jì) ? 缺乏或不完整、不一致的文檔給維護(hù)帶來(lái)困難 ? 用戶對(duì)軟件需求的描述往往不夠精確，有遺漏，有二義 ? 軟件開(kāi)發(fā)人員對(duì)需求的理解與用戶的本來(lái)愿望有差異 ? 大型軟件項(xiàng)目需多人協(xié)同完成，缺乏管理經(jīng)驗(yàn) ? 開(kāi)發(fā)人員不能有效地、獨(dú)立自主地處理大型軟件的全部關(guān)系 ? 缺乏有力的方法學(xué)和工具的支持 ? 軟件項(xiàng)目的特殊性和人類智力的局限性 12 克服軟件危機(jī)的途徑 ? 消除 錯(cuò)誤的概念和做法 ? 推廣 使用成功的開(kāi)發(fā)技術(shù)和方法 ? 使用 軟件工具和軟件工程支持環(huán)境 ? 加強(qiáng)軟件 管理 擺脫軟件危機(jī)的出路： 軟件開(kāi)發(fā)的 工程化 和 標(biāo)準(zhǔn)化 13 軟件工程相關(guān)概念 ? 軟件工程 : 軟件工程是用科學(xué)知識(shí)和技術(shù)原理來(lái)定義、開(kāi)發(fā)、維護(hù)軟件的一門綜合性的交叉學(xué)科，軟件工程是開(kāi)發(fā)與維護(hù)軟件的規(guī)范化系統(tǒng)方法。 15 軟件工程三要素 ? 軟件工程方法 ? 軟件工具 ? 軟件工程過(guò)程 為軟件開(kāi)發(fā)提供“如何做”的技術(shù)。軟件開(kāi)發(fā)的不同階段可使用不同的工具。 一般來(lái)說(shuō) ， 整個(gè)生存周期包括 計(jì)劃 、 開(kāi)發(fā) 、 運(yùn)行 三個(gè)時(shí)期 ， 每一個(gè)時(shí)期又劃分為若干階段 。 從邏輯模型出發(fā) ， 經(jīng)過(guò)壓縮的設(shè)計(jì) ， 找出幾種可供選擇的解決辦法 。 技術(shù)可行性分析通常包括風(fēng)險(xiǎn)分析 、 資源分析和技術(shù)分析 ? 三個(gè)方面的可行性 24 ? 風(fēng)險(xiǎn)分析 ：分析在給定的約束條件下設(shè)計(jì)和實(shí)現(xiàn)系統(tǒng)的風(fēng)險(xiǎn)。 26 ? 技術(shù)分析 ：分析當(dāng)前的科學(xué)技術(shù)是否支持系統(tǒng)開(kāi)發(fā)的各項(xiàng)活動(dòng)。 ?在進(jìn)行成本效益分析時(shí)通常只統(tǒng)計(jì)五年內(nèi)的經(jīng)濟(jì)效益。 2． 可行性研究前提 。 6． 社會(huì)因素的可行性分析 。 結(jié)構(gòu)化分析方法 和 面向?qū)ο蠓治龇椒? 1. 需求分析概念 43 是要準(zhǔn)確地定義新系統(tǒng)的目標(biāo) ， 滿足用戶需要 。 另外還有可靠性、安全性、保密性、可移植性、可維護(hù)性等方面的需求 . 這些需求一般通過(guò)雙方交流、調(diào)查研究來(lái)獲取，并達(dá)到共同的理解。 （ 3）編寫文檔。 46 3. 結(jié)構(gòu)化分析方法 （ 1） 數(shù)據(jù)流圖 （ DFD） 數(shù)據(jù)流圖 （ Data Flow Diam） ， 是 SA方法中用于表示系統(tǒng)邏輯模型的一種工具 ， 它以圖形的方式描繪數(shù)據(jù)在系統(tǒng)中流動(dòng)和處理的過(guò)程 ， 由于它只反映系統(tǒng)必須完成的邏輯功能 ， 所以它是一種功能模型 。 ?判定結(jié)構(gòu) ： if_then_else 或 case_of 結(jié)構(gòu)； 53 商店業(yè)務(wù)處理系統(tǒng)中“檢查發(fā)貨單” if 發(fā)貨單金額超過(guò) $500 then if 欠款超過(guò)了 60天 then 在償還欠款前不予批準(zhǔn) else （欠款未超期） 發(fā)批準(zhǔn)書(shū)，發(fā)貨單 else （發(fā)貨單金額未超過(guò) $500） if 欠款超過(guò) 60天 then 發(fā)批準(zhǔn)書(shū)，發(fā)貨單及賒欠報(bào)告 else （欠款未超期） 發(fā)批準(zhǔn)書(shū)，發(fā)貨單 54 2）判定表 ? 如果數(shù)據(jù)流圖的加工需要依賴于 多個(gè)邏輯條件的取值 ，使用判定表來(lái)描述比較合適 條件定義 條件取值的組合 動(dòng)作定義 在各種取值的組合下應(yīng)執(zhí)行的動(dòng)作 55 以“檢查發(fā)貨單”為例 56 3） 判定樹(shù) ? 判定樹(shù)也是用來(lái)表達(dá)加工邏輯的一種工具。 3. 結(jié)構(gòu)化分析方法 數(shù)據(jù)字典主要有四類條目： 數(shù)據(jù)流、數(shù)據(jù)項(xiàng)、數(shù)據(jù)存儲(chǔ)、基本加工。 63 1. 軟件概要設(shè)計(jì) ? 概要設(shè)計(jì)基本任務(wù) ? 概要設(shè)計(jì)基本原理 64 （ 1）概要設(shè)計(jì)基本任務(wù) 1) 進(jìn)行軟件系統(tǒng)總體結(jié)構(gòu)設(shè)計(jì) 2)進(jìn)行軟件中所使用的數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫(kù)的設(shè)計(jì) 3)編寫概要設(shè)計(jì)文檔 4)進(jìn)行概要設(shè)計(jì)的評(píng)審 65 （ 1）概要設(shè)計(jì)基本任務(wù) 1) 軟件系統(tǒng)總體結(jié)構(gòu)設(shè)計(jì) a. 采用某種設(shè)計(jì)方法 ， 將一個(gè)復(fù)雜的系統(tǒng)按功能劃分成模塊 。 e. 評(píng)價(jià)模塊結(jié)構(gòu)的質(zhì)量。 67 （ 1）概要設(shè)計(jì)基本任務(wù) 3) 概要設(shè)計(jì)文檔主要包括： a. 概要設(shè)計(jì)說(shuō)明書(shū) 。 68 （ 1）概要設(shè)計(jì)基本任務(wù) 4) 進(jìn)行概要設(shè)計(jì)的評(píng)審 ： 對(duì)設(shè)計(jì)部分是否完整地實(shí)現(xiàn)了需求中規(guī)定的功能 、性能等要求 設(shè)計(jì)方案的可行性 內(nèi)外部接口定義的正確性 、 有效性 各部分之間的一