軟件工程-第3章軟件需要分析
《軟件工程-第3章軟件需要分析》由會員分享,可在線閱讀,更多相關(guān)《軟件工程-第3章軟件需要分析(236頁珍藏版)》請在裝配圖網(wǎng)上搜索。
1、LOGO 第 5章 軟件需求分析 為什么要進行需求分析? 目的:對開發(fā)者進行指導(dǎo) 開發(fā)人員對用戶的要求理解 用戶理解開發(fā)人員 測試部門有理可依 原因:信息收集不全 功能不明確 需求文檔不完善 開發(fā)者急于求成 教學(xué)內(nèi)容 3.1 需求分析的任務(wù)和步驟 3.2 需求獲取的常用方法 3.3 分析建模 3.4 軟件需求說明 3.5 結(jié)構(gòu)化分析方法 3.6 面向?qū)ο蠓治龇椒?教學(xué)目的及要求 深刻理解需求分析階段的概念和任務(wù); 熟練掌握數(shù)據(jù)流圖; 了解面向過程分析方法和面向?qū)ο蟮姆治龇椒ā?1.需求分析的任務(wù): 準(zhǔn)確地定義未來系統(tǒng)的目標(biāo),確定為了滿足用戶的需求系統(tǒng)必須做 什么。用 規(guī)范的形式準(zhǔn)確地表達(dá)用戶的
2、需求。 讓用戶和開發(fā)者共同明確將要開發(fā)的是一個什么樣的系統(tǒng)(做什么 : What)。具體而言 ,兩個任務(wù): 建立分析模型 編寫需求說明( P30-P31) 3.1 需求分析的任務(wù)和步驟 需求分析的任務(wù) 就是借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系 統(tǒng)的邏輯模型,解決目標(biāo)系統(tǒng)的 “做什么” 的問題。 需求分析的任務(wù) 對象 系統(tǒng) 模型 系統(tǒng) 抽象(映射) 模型應(yīng)用 模型構(gòu)造的過程 邏輯模型和物理模型 模型是對對象系統(tǒng)的形式化的特征抽象,概括性或近似地表示; 形式 化語言、數(shù)學(xué)語言、圖形等構(gòu)造模型的過程是一個抽象、分析的過程。 邏輯模型和物理模型 邏輯模型 (本質(zhì)模型、概念模型 ) 物理模型 (實施模型、
3、技術(shù)模型 ) 現(xiàn)行系統(tǒng) 描述重要的業(yè)務(wù)功能,無論系統(tǒng)是 如何實施的 描述現(xiàn)實系統(tǒng)是如何在 物理上實現(xiàn)的。 目標(biāo)系統(tǒng) 描述新系統(tǒng)的主要業(yè)務(wù)功能和用戶 新的需求,無論系統(tǒng)應(yīng)如何實施。 描述新系統(tǒng)是如何實施 的(包括技術(shù))。 2.需求分析的步驟 需求獲取 需求提煉:分析建模 需求描述:編寫 需求驗證 3.1 需求分析的任務(wù)和步驟 需求分析過程示意 學(xué) 生 購 書 申 請 購 書 單 發(fā) 票 領(lǐng) 書 單 書 107 劉 教務(wù)科 206 王 會計室 206 李 出納員 303 趙 教材 學(xué)生購買教材的具體模型 (1) 通過對現(xiàn)實環(huán)境的調(diào)查,獲當(dāng)前系統(tǒng)的具體模型 (物理模型 ) 學(xué) 生 需求分析過程示意
4、(2) 去掉具體模型中的非本質(zhì)因素, 抽象 出當(dāng)前系統(tǒng)的邏輯 模型 學(xué)生購買教材的邏輯模型 學(xué) 生 學(xué) 生 購 書 申 請 購 書 單 發(fā) 票 領(lǐng) 書 單 書 審查 有效性 開發(fā)票 開領(lǐng) 書單 發(fā)書 需求分析過程示意 (3) 分析當(dāng)前系統(tǒng)與目標(biāo)系統(tǒng)的差別,建立目標(biāo)系統(tǒng)的邏輯 模型。 計算機售書系統(tǒng)的邏輯模型 學(xué) 生 學(xué) 生 購書單 發(fā)票 領(lǐng)書單 審查并 開發(fā)票 開領(lǐng) 書單 需求分析過程示意 (4) 對目標(biāo)系統(tǒng)進行完善和補充,并寫出完整的需求說明; (5) 對需求說明進行復(fù)審,直到確認(rèn)文檔齊全,并且符合用 戶的全部需求為止。 3.2 需求獲取的常用方法 1.需求獲取的目的 清楚地理解所要解決的問
5、題 完整地獲取用戶需求 2.需求獲取面臨的挑戰(zhàn) 問題的復(fù)雜性和對問題空間理解的不完 備性與不一致性 交流障礙 需求易變性 3.2 需求獲取的常用方法 3.需求獲取的常用方法( P34-P35) 建立聯(lián)合分析小組 客戶訪談 問題分析與確認(rèn) 3.2 需求獲取的常用方法 建立聯(lián)合分析小組 1)聯(lián)合分析小組的人員主要包括:用戶、領(lǐng)域?qū)<摇?系 統(tǒng)分析員 2)通過聯(lián)合分析小組的工作,可以極大地方便系統(tǒng)開發(fā) 人員和用戶之間的溝通。 3.需求獲取的常用方法 客戶訪談 在與用戶接觸之前,先要進行充分的準(zhǔn)備 : 注意:在與用戶交流時,應(yīng)遵循循序漸進、逐步逼近的原則, 切不可急于求成否則欲速則不達(dá)。 3.需求獲取
6、的常用方法 首先,必須對問題的背景和問題所在系統(tǒng)的環(huán)境有全面的了解; 其次,盡可能了解將要會談用戶的個性特點及任務(wù)狀況; 第三,事先準(zhǔn)備一些問題。 問題分析與確認(rèn) 不能期望用戶在一兩次交談中,就會對目標(biāo)軟件的 要求闡述清楚,也不能限制用戶在回答問題過程中的自 由發(fā)揮。 在每次訪談之后,要及時進行整理,分析用戶提供 的信息,去掉錯誤的、無關(guān)的部分,整理有用的內(nèi)容, 以便在下一次與用戶見面時由用戶確認(rèn);同時,準(zhǔn)備下 一次訪談時的進一步更細(xì)節(jié)的問題。如此循環(huán),一般需 要 2-5個來回。 3.需求獲取的常用方法 舉例:某出版社系統(tǒng)調(diào)查表 編號 提出問題 1 您在哪個部門工作? 2 出版業(yè)務(wù)流程是什么?
7、 3 您每日都處理那些文件、數(shù)據(jù)、報表? 4 工作中手工處理特別麻煩的事情是什么? 5 工作中手工處理什么問題解決不了?影響效率的問題有哪些? 6 您認(rèn)為提高工作效率,節(jié)省工作時間,減輕工作強度可采取哪些 辦法? 舉例:某出版社系統(tǒng)調(diào)查表 編號 提出問題 7 您的部門需要成本核算和統(tǒng)計的內(nèi)容有哪些? 8 您的部門采用計算機管理工作情況如何? 9 如何改進業(yè)務(wù)流程使之更合理? 10 哪些問題是目前傳統(tǒng)手工方法根本無法解決的? 11 出版社計算機管理信息系統(tǒng)需要解決什么問題? 軟件需求分析的通信途徑 需求分析流程 4. 需求獲取的內(nèi)容 (1)功能性需求 : 定義了系統(tǒng)做什么(描述系統(tǒng)必須支持的功能
8、和過程) (2)非功能性需求(技術(shù)需求) : 定義了系統(tǒng)工作時的特性(描述操作環(huán)境和性能目標(biāo)) 用戶需求分類 兩類需求包括的內(nèi)容 (1) 功能 (2) 性能 (3) 環(huán)境 (4) 界面 (5) 用戶或人的因素 (6) 文檔 (7) 數(shù)據(jù) (8) 資源 (9) 安全保密 (10)軟件成本消耗與開發(fā)進度 (11)質(zhì)量保證 4. 需求獲取的內(nèi)容 (1) 功能需求 系統(tǒng)做什么? 系統(tǒng)何時做什么? 系統(tǒng)何時及如何修改或升級? (2) 性能需求 軟件開發(fā)的技術(shù)性指標(biāo) 例如: 存儲容量限制 執(zhí)行速度、相應(yīng)時間 吞吐量 (3) 環(huán)境需求 硬件設(shè)備:機型、外設(shè)、接口、地 點、分布、溫度、濕度、磁場干擾等 軟件:
9、 操作系統(tǒng) 網(wǎng)絡(luò) 數(shù)據(jù)庫 (4) 界面需求 有來自其它系統(tǒng)的輸入嗎? 到自其它系統(tǒng)的輸出嗎? 對數(shù)據(jù)格式有規(guī)定嗎? 對數(shù)據(jù)存儲介質(zhì)有規(guī)定嗎? 需求包括的內(nèi)容 (5) 用戶或人的因素 用戶類型? 各種用戶熟練程度? 需受何種訓(xùn)練? 用戶理解、使用系統(tǒng)的難度? 用戶錯誤操作系統(tǒng)的可能性? (6) 文檔需求 需哪些文檔? 文檔針對哪些讀者? (7) 數(shù)據(jù)需求 輸入、輸出數(shù)據(jù)的格式? 接收、發(fā)送數(shù)據(jù)的頻率? 數(shù)據(jù)的準(zhǔn)確性和精度? 數(shù)據(jù)流量? 數(shù)據(jù)需保持的時間? (8) 資源需求 軟件運行時所需的數(shù)據(jù)、軟件、 內(nèi)存空間等資源。 軟件開發(fā)、維護所需的人力、支 撐軟件、開發(fā)設(shè)備等。 需求包括的內(nèi)容 (9)
10、安全保密要求 需對訪問系統(tǒng)或系統(tǒng)信息加以控制嗎? 如何隔離用戶之間的數(shù)據(jù)? 用戶程序如何與其它程序和操作系統(tǒng)隔離? 系統(tǒng)備份要求? (10) 軟件成本消耗與 開發(fā)進度需求 開發(fā)有規(guī)定的時間表嗎? 軟硬件投資有無限制? (11) 質(zhì)量保證 系統(tǒng)的可靠性要求? 系統(tǒng)必須監(jiān)測和隔離錯誤嗎? 規(guī)定系統(tǒng)平均出錯時間? 出錯后,重啟系統(tǒng)允許的時間? 系統(tǒng)變化如何反映到設(shè)計中? 維護是否包括對系統(tǒng)的改進? 系統(tǒng)的可移植性? 需求包括的內(nèi)容 原型 (原型指 “ 快速軟件原型 ” )是一個可實地 運行 的 模型 ,有正式產(chǎn)品的主要特征,但不是全部特征。 軟件原型是軟件系統(tǒng)的最初版本,以最少的費用,最 短的時間開
11、發(fā)出的、以反映最后軟件的主要特征的系統(tǒng)。 5. 快速原型法在需求分析中的應(yīng)用 原型開發(fā)指的是建立一個系統(tǒng)的早期版本的演習(xí) (practice),它不必反映最終產(chǎn)品的所有性能,而只要反映感 興趣的一些方面。 原型的定義 原型的作用 問題:開發(fā)初期很難確定用戶需求規(guī)格解決:用戶與開發(fā) 者之間的鴻溝以原型 (軟件產(chǎn)品的樣品 )為共同語言,實現(xiàn)用戶 與開發(fā)者雙向溝通。 原型的特性 是一個可實際工作的系統(tǒng); 沒有固定的生存期 ,結(jié)局可能是用后立即被拋棄 ,或可能成為 最終系統(tǒng) ; 可服務(wù)于不同的目的 , 從需求分析到最終產(chǎn)品都可做原型 ; 建立必須快 ,便宜 ; 是包含修改 、 評價在內(nèi)的完整重復(fù)過程
12、需求分析和定義規(guī)格說明 作為軟件設(shè)計的一種工具 作為一種解決不確定性的工具 作為一種實驗工具 系統(tǒng)開發(fā)同時 ,作為同步培訓(xùn)工具 作為開發(fā)方法,利用原型演化為最終系統(tǒng) 作為軟件維護的輔助工具 原型化開發(fā)的應(yīng)用領(lǐng)域 原型開發(fā)的步驟 (1) 利用各種分析技術(shù)和方法,生成一個建華的需求規(guī)格說明。 (2) 對需求規(guī)格說明進行必要的檢查和修改后,確定原型的軟件結(jié)構(gòu)、 用戶界面和數(shù)據(jù)結(jié)構(gòu)等。 (3) 在現(xiàn)有的工具和環(huán)境的幫助下快速生成可運行的軟件原型并進行測 試、改進; (4)將原型提交給用戶評估并征求用戶的修改意見; (5)重復(fù)上述過程,直到原型得到用戶的認(rèn)可。 原型化的開發(fā)環(huán)境 (1)試驗性原型 原型用
13、來確認(rèn)對需求的理解是否正確,應(yīng)在與實際產(chǎn)品環(huán) 境相近的環(huán)境上開發(fā)原型。 (2) 試用性原型 原型用來幫助用戶在試用中使自己的模糊的需求明確起來 確,可在與實際產(chǎn)品環(huán)境完全 無關(guān)的環(huán)境上開發(fā)運行。 僅對屏幕的原型化 使用購買的軟件系統(tǒng)作為 初始模型 可行性分析中的原型 子系統(tǒng)原型化 原型化策略 功能原型開發(fā) 用戶界面原型開發(fā) 原型開發(fā)技術(shù) 原型化工具 面向應(yīng)用的第四代語言 (4GL) Delphi VB PowerBuilder Visual C+ 等 原型法效果 保證產(chǎn)品有較好的可維護性 改善用戶與開發(fā)人員的信息交流和思想溝通,給用戶修改的機會 減少或消滅下游返工的可能,改進了瀑布模型的弊病
14、原型系統(tǒng)可作為培訓(xùn)環(huán)境 ,有利于用戶培訓(xùn)和開發(fā)同步。 開發(fā)成本降低,周期縮短。 原型法局限性 需工具支持 , 否則開發(fā)工作量大; 只能縮短用戶與軟件需求定義間的距離 , 并不能消滅這個距離; 考慮你的項目是否適合用原型法來開發(fā)時 , 有幾個因素是要權(quán)衡的 。 Boehm,Gray,和 Seewaldt(1984) 研究了項目是否適合用原型來開發(fā)的 問題 。 他們發(fā)現(xiàn)用原型法開發(fā)項目 , 可以少花費 45%的努力 , 還可以 減少 40%的代碼 。 而且 , 開發(fā)出的產(chǎn)品的速度和效率與用傳統(tǒng)方法開 發(fā)出的差不多 。 是否要選擇原型法? 由于開發(fā)一個原型需要花費一定的人力、物力、財力和時間, 而且
15、用于確定需求的原型在完成使命后一般就被丟棄。因此,是 否使用快速原型法必須考慮軟件系統(tǒng)的特點、可用的開發(fā)技術(shù)和 工具等方面。 Andriole提出的一下 6個問題,可用來幫助判斷是 否要選擇原型法。 需求已經(jīng)建立,并且可以預(yù)見是相當(dāng)穩(wěn)定嗎?(肯定回答,不 采用原型法) 軟件開發(fā)人員和用戶已經(jīng)理解了目標(biāo)軟件的應(yīng)用領(lǐng)域嗎? 問題是否可被模型化? 用戶能否清楚地確定基本的系統(tǒng)需求? 有任何需求是含糊的嗎? 已知的需求中存在矛盾嗎? (以上 5個問題肯定回答,用原型法) 3.3 分析建模 兩種分析模型 結(jié)構(gòu)化分析模型 面向?qū)ο蠓治瞿P?計算機世界 現(xiàn)實世界 結(jié) 構(gòu) 化 開 發(fā) 方 法 結(jié)構(gòu)化 分析 結(jié)
16、構(gòu)化 設(shè)計 結(jié)構(gòu)化 編程 OOA OOD OOP 面 向 對 象 開 發(fā) 方 法 結(jié)構(gòu)化分析模型的組成結(jié)構(gòu) 數(shù)據(jù)流圖 (DFD) E-R圖 狀態(tài)變遷圖 (STD圖 ) 加 工 說 明 控制說明 數(shù) 據(jù) 對 象 說 明 數(shù)據(jù)字典 ( DD) 結(jié)構(gòu)化分析模型的組成結(jié)構(gòu) 模型的核心是 DD( Data Dictionary,數(shù)據(jù)字典),它是系統(tǒng)所涉及的 各種數(shù)據(jù)對象的總和。 從 DD出發(fā)可構(gòu)建 3種圖: E-R圖 ( Entity-Relation Diagram,實體 -關(guān)系圖)用于描述數(shù)據(jù)對 象間的關(guān)系,他代表軟件的數(shù)據(jù)模型,在實體 -關(guān)系圖中出現(xiàn)的每個 數(shù)據(jù)對象的屬性均可用數(shù)據(jù)對象說明來描述;
17、 DFD圖 ( Data Flow Diagram,數(shù)據(jù)流圖),其主要作用是指明系統(tǒng)中 數(shù)據(jù)是如何流動和變換的,以及描述是數(shù)據(jù)流進行變換的功能,在 DFD圖中出現(xiàn)的每個功能的描述則寫在( PSPEC)中,它們一起構(gòu)成功 能模型; STD( Status Transfer Diaram,狀態(tài) -變遷圖),用于指明系統(tǒng)在外 部時間的作用下將會如何動作,表明了系統(tǒng)的各種狀態(tài)以及各種狀態(tài) 間的變遷,從而構(gòu)成為行為模型的基礎(chǔ),關(guān)于軟件控制方面的附加信 息則包含在控制說明( CSPEC)。 面向?qū)ο蠓治瞿P偷慕M成結(jié)構(gòu) 對象 -關(guān) 系模型 類 /對象 模型 對象 -行為模型 使用實例 (Use Case)
18、操作、 面向?qū)ο蠓治瞿P偷慕M成結(jié)構(gòu) 使用實例, 處于 OOA模型核心的是“使用實例”( Use Case ),簡稱 “用例”。獲得軟件的需求后,軟件分析員既可據(jù)此創(chuàng)建一組“場景” ( Scenario),每個場景包含一個使用實例。從這些用例出發(fā),進一 步抽取和定義 OOA模型的 3種模型,即 類 -對象模型 , 描述系統(tǒng)所涉及的全部類 -對象,每個類 -對象都通過 屬性、操作和寫作者來進行進一步描述; 對象 -關(guān)系模型 , 描述對象之間的靜態(tài)關(guān)系,同時定義了系統(tǒng)中所有 重要的消息路徑,它也可以具體化到對象的屬性、操作和協(xié)作者; 對象 -行為模型 , 描述了系統(tǒng)的動態(tài)行為,即對湘雜特定的狀態(tài)下如
19、 何反映外界的事件。 數(shù)據(jù)流圖 (DFD) 數(shù)據(jù)字典 (DD) 加工說明 控制流圖( CFD)與控制說明( CSPEC ) 狀態(tài)轉(zhuǎn)換圖 (STD) E-R圖 用例圖 對象關(guān)系圖( Object-Relationship,O-R) 對象行為圖 2.分析模型的組成與描述工具 分析模型的組成與描述工具 DFD、 DD和 PSPEC:是早期結(jié)構(gòu)化分析模型 的基本組成部分; CFD、 CSPEC和 STD是擴展成分用以適應(yīng)實時的 建模需要; E-R圖:適用于描述具有復(fù)雜數(shù)據(jù)結(jié)構(gòu)的軟件數(shù)據(jù) 模型; 用例圖、對象關(guān)系圖和對象行為圖適用于 OOA的分 析模型。 數(shù)據(jù)流圖 (DFD) 任何軟件系統(tǒng)(或計算機系統(tǒng)
20、)從根本上說,都是對數(shù)據(jù) 進行加工或變換的工具 指明數(shù)據(jù)在系統(tǒng)中移動時如何被變換; 描述對數(shù)據(jù)流進行變換的功能; DFD中每個功能的描述包含在加工規(guī)約小說明 )中。 數(shù)據(jù)存儲 (文件或數(shù)據(jù)庫) 數(shù)據(jù)流圖的四個基本成分 數(shù)據(jù)流(數(shù)據(jù)對象) 位于被建模系統(tǒng)之外的信息生產(chǎn)者或消費者 , 稱為外部項。 說明數(shù)據(jù)輸入的源點 (數(shù)據(jù)源 )或數(shù)據(jù)輸出的 匯點 (數(shù)據(jù)池 ) 或 2 或 2 或 II 數(shù)據(jù)處理 (加工 ) 數(shù)據(jù)流 表示數(shù)據(jù)和數(shù)據(jù)流向, 三個重要屬性 : 流向 (從加工出發(fā)或流向加工 ) 數(shù)據(jù)組成 數(shù)據(jù)流名字 數(shù) 據(jù)流命名方法和注意事項 用名詞或名詞詞組,不要使用意義空洞的名詞; 盡量使用現(xiàn)實系
21、統(tǒng)已有名字 ,當(dāng)命名出現(xiàn)困難,考慮是否數(shù)據(jù)流劃 分不恰當(dāng); 不要把控制流作為數(shù)據(jù)流指明作為外部事件的結(jié)果 ,系統(tǒng)將如何動 作。 舉例 : 購 書 單 發(fā)票 領(lǐng)書單 審查并 開發(fā)票 開領(lǐng) 書單 無效書單 學(xué)生 1 2 各班學(xué)生 用 書 表 學(xué)生 教材存量表 數(shù)據(jù)字典 (DD, Data Dictionary) 模型核心 (中心庫 ) 一個軟件系統(tǒng)含有許多數(shù)據(jù)。數(shù)據(jù)字典的作用,就是對軟件中 的每個數(shù)據(jù)規(guī)定一個定義條目,以保持?jǐn)?shù)據(jù)在系統(tǒng)中的一致性。 由字典統(tǒng)一給出的所有數(shù)據(jù)的定義與屬性,已成為結(jié)構(gòu)化分析 中分析建模的基礎(chǔ)。 數(shù)據(jù)詞典與數(shù)據(jù)流圖配合,能清楚地表達(dá)數(shù)據(jù)處理的要求 詞條描述 對于在數(shù)據(jù)流圖
22、中每一個被命名的圖形元素, 均加以定義,其內(nèi)容有 : 名字 , 別名或編號 , 分類 , 描述 , 定 義 , 位置 , 其它 , 等 數(shù)據(jù)字典 DD是對所有與系統(tǒng)相關(guān)的數(shù)據(jù)元素的一個有組織的列表 ,以及 精確的、嚴(yán)格的定義 ,使得用戶和系統(tǒng)分析員對于輸入、輸出、 存儲成分和中間計算有共同的理解 DFD中的數(shù)據(jù)流、數(shù)據(jù)存儲表示某個有組織的數(shù)據(jù)集合,它 們要由 SA的其他描述工具 -需求字典 (數(shù)據(jù)字典 )來描述,包括: 詞條描述、 數(shù)據(jù)結(jié)構(gòu)描述、 加工邏輯說明 作用 : 數(shù)據(jù)字典 數(shù)據(jù)字典是關(guān)于數(shù)據(jù)的信息的集合,也就是對數(shù)據(jù)流圖中包含的所有元素的定 義的集合 數(shù)據(jù)字典的內(nèi)容 數(shù)據(jù)流 數(shù)據(jù)流分量
23、 數(shù)據(jù)存儲 處理 數(shù)據(jù)處理:用 IPO圖或 PDL描述比較方便直觀。 數(shù)據(jù)元素的別名: 定義數(shù)據(jù)的方法 由數(shù)據(jù)元素組成數(shù)據(jù)的方式的三種基本類型 順序 +: 以確定次序連接兩個或多個分量 a+b+c 選擇 |, : 從兩個或多個可能的元素中選取一個 a | b | c 重復(fù) : 把指定的分量重復(fù)零次或多次 a 可選:一個分量是可有可無的(重復(fù)零次或一次) , ( a) 例子 定貨報表 =零件編號 +零件名稱 +定貨數(shù)量 +目前價格 +主要供應(yīng)者 +次要供應(yīng)者 零件編號 =8字符 8 定貨數(shù)量 =1數(shù)字 5 數(shù)據(jù)流詞條描述 數(shù)據(jù)流名: 說明:簡要介紹作用即它產(chǎn)生的原因和結(jié)果 數(shù)據(jù)流來源:來自何方
24、數(shù)據(jù)流去向:去向何處 數(shù)據(jù)流組成:數(shù)據(jù)結(jié)構(gòu) 數(shù)據(jù)量流通量:數(shù)據(jù)量,流通量 數(shù)據(jù)元素詞條描述 數(shù)據(jù)元素名: 類型:數(shù)字(離散值,連續(xù)值),文字(編碼類型) 長度: 取值范圍: 相關(guān)的數(shù)據(jù)元素及數(shù)據(jù)結(jié)構(gòu): 數(shù)據(jù)文件詞條描述 數(shù)據(jù)文件名: 簡述:存放的是什么數(shù)據(jù) 輸入數(shù)據(jù): 輸出數(shù)據(jù): 數(shù)據(jù)文件組成:數(shù)據(jù)結(jié)構(gòu) 存儲方式:順序,直接,關(guān)鍵碼 存取頻率: 加工邏輯詞條描述 加工名: 加工編號:反映該加工的層次 簡要描述:加工邏輯及功能簡述 輸入數(shù)據(jù)流: 輸出數(shù)據(jù)流: 加工邏輯:簡述加工程序,加工順序 F1:航班信息文件 航空公司名稱航班號 起點終點日期 起飛時間降落時間 航空公司名稱 2字母 4 航班號
25、 3十進制數(shù)字 3 字母“ A”“Z” 十進制數(shù)字“ 0”“9” 起點終點 1漢字 10 起飛時間降落時間時分 時“ 00”“23” 分“ 00”“59” 日期年月日 年 2000 2001 2002 2004 月“ 01”“12” 日“ 01”“31” 重復(fù)項: 起點終點 1漢字 10 航空公司名稱 2字母 4 航班號 3十進制數(shù)字 3 組合項: 日期年月日 起飛時間降落時間時分 選擇項: 年 2000 2001 2002 2004 原數(shù)據(jù)項: 字母“ A”“Z” 十進制數(shù)字“ 0”“9” 時“ 00”“23” 分“ 00”“59” 月“ 01”“12” 日“ 01”“31” 定義式中使用的
26、符號 操作符 含義描述 定義為 與 (順序結(jié)構(gòu) ) . 重復(fù) (循環(huán)結(jié)構(gòu) ) . . 或 (選擇結(jié)構(gòu) ) . , . ( . ) 任選 m.n 界域 ., 注釋符 限制重復(fù)次數(shù)舉例 : 3 5 或 5 3 表示允許重復(fù) 3-5次 3 3 或 3 3 表示恰好重復(fù) 3 次 1 表示至少出現(xiàn) 1 次 表示允許重復(fù) 0至任意次 源點及匯 (終 )點詞條描述 簡名稱:外部實體名 要描述:什么外部實體 有關(guān)數(shù)據(jù)流: 數(shù)目: 數(shù)據(jù)結(jié)構(gòu)的描述 符 號 含 義 舉 例 被定義為 與 x = a b .,. 或 .|. 或 x = a , b, x = a | b . 或 m.n 重復(fù) x = a, x = 3
27、a8 (.) 可選 x = (a) “.” 基本數(shù)據(jù)元素 x = “ a” . 連結(jié)符 x = 1.9 存折格式 存折戶名所號帳號開戶日性質(zhì) (印密 ) 1存取行 50 戶名 2字母 24 所號“ 001”.“999” 帳號“ 00000001”.“99999999” 開戶日年月日 性質(zhì)“ 1”.“6” 注:“ 1” 表示普通戶,“ 5” 表示工資戶等 印密“ 0” 注:印密在存折上不顯示 存取行日期(摘要)支出存入余額操作復(fù)核 出現(xiàn)在軟件中的數(shù)據(jù)可分為 3種情況: 只含一個數(shù)據(jù)的數(shù)據(jù)項(或數(shù)據(jù)元素); 由多個相關(guān)數(shù)據(jù)向組成的數(shù)據(jù)流; 數(shù)據(jù)文件或數(shù)據(jù)庫。 舉例說明怎樣編寫各類數(shù)據(jù)的字典條目:
28、數(shù)據(jù)流 數(shù)據(jù)文件 數(shù)據(jù)項 數(shù)據(jù)流條目說明舉例 數(shù)據(jù)流名 :發(fā)票 別名 : 購書發(fā)票 組成 :(學(xué)號 )姓名書號單價數(shù)量總價 書費合計 數(shù)據(jù)量 :100次 /天 高峰值:開學(xué)期間 400次 /天 數(shù)據(jù)存儲條目說明舉例 文件名 :各班學(xué)生用書表 別名 : 組成 : 系編號專業(yè)和班編號 年級 書號 組織 :按系、專業(yè)和班編號從小到大 排列 存取要求 :關(guān)鍵字是專業(yè)和班編號 數(shù)據(jù)項條目說明舉例 數(shù)據(jù)項名 :系編號 別名 : 取值: 2數(shù)字 2 注釋 : * 例如 : 01,12 * 數(shù)據(jù)項條目說明舉例 數(shù)據(jù)項名 :專業(yè)和班編號 別名 : 取值: 3數(shù)字 3 注釋 : * 例如 : 305 * 數(shù)據(jù)項條
29、目說明舉例 數(shù)據(jù)項名 :年級 別名 : 取值及含義 : freshmen, 一年級 sophomore,二年級 junjor, 三年級 senior, 四年級 注釋 :F,M,J,S可分別用 1,2,3,4代替 數(shù)據(jù)項條目說明舉例 數(shù)據(jù)項名 :書號 別名 : 取值 : 字母 數(shù)字 注釋 : * 例如 :, * 對數(shù)據(jù)流圖的每一個基本加工,必須有一個基本加工邏輯說明 基本加工邏輯說明必須描述基本加工 如何把輸入數(shù)據(jù)流變換為 輸出數(shù)據(jù)流的加工規(guī)則 加工邏輯說明必須描述實現(xiàn)加工的策略而不是實現(xiàn)加工的細(xì)節(jié) 加工邏輯說明中包含的信息應(yīng)是充足的,完備的,有用的,無 冗余的 基本加工邏輯說明 用于寫加工邏輯
30、說明的工具 結(jié)構(gòu)化英語 判定表 判定樹 結(jié)構(gòu)化英語 結(jié)構(gòu)化英語的詞匯表由 英語命令動詞 數(shù)據(jù)詞典中定義的名字 有限的自定義詞 邏輯關(guān)系詞 IF_THEN_ELSE、 CASE_OF 、 WHILE_DO、 REPEAT_UNTIL等組成。 是一種介于自然語言和形式化語言之間的語言 語言的 正文用基本控制結(jié)構(gòu)進行分割 ,加工中的 操 作用自然語言短語來表示 其基本控制結(jié)構(gòu)有三種: 簡單陳述句結(jié)構(gòu) :避免復(fù)合語句; 重復(fù)結(jié)構(gòu) : while_do 或 repeat_until 結(jié)構(gòu)。 判定結(jié)構(gòu) : if_then_else 或 case_of 結(jié)構(gòu); 商店業(yè)務(wù)處理系統(tǒng)中 “ 檢查發(fā)貨單 ” if
31、發(fā)貨單金額超過 $500 then if 欠款超過了 60天 then 在償還欠款前不予批準(zhǔn) else (欠款未超期) 發(fā)批準(zhǔn)書,發(fā)貨單 else (發(fā)貨單金額未超過 $500) if 欠款超過 60天 then 發(fā)批準(zhǔn)書,發(fā)貨單及賒欠報告 else (欠款未超期) 發(fā)批準(zhǔn)書,發(fā)貨單 判定表 如果數(shù)據(jù)流圖的加工需要依賴于 多個邏輯條件的取 值 ,使用判定表來描述比較合適 以 “ 檢查發(fā)貨單 ” 為例 判定樹 判定樹也是用來表達(dá)加工邏輯的一種工具。有時侯 它比判定表更直觀。 檢 查 發(fā) 貨 單 金額 $500 金額 $500 欠款 60天 不發(fā)出批準(zhǔn)書 欠款 60天 發(fā)貨單 發(fā)出批準(zhǔn)書、 欠款
32、60天 發(fā)出批準(zhǔn)書、 發(fā)貨單及賒欠報告 欠款 60天 發(fā)出批準(zhǔn)書、 發(fā)貨單 控制流圖( CFD)與控制說明( CSPEC) CFD是為了適應(yīng)實施系統(tǒng)地分析而提出的,通常與 DFD配合使用,目的使 CSPEC分析員在用 DFD和 PSPEC表 示數(shù)據(jù)流和加工的同時,也能夠用 CFD和 CSPEC表示控 制流和控制加工。( P45-P47) 數(shù)據(jù)流和控制流舉例 動作 警告 監(jiān)控固件和 操作接口 每個固件狀態(tài) 機器人初 始化控制 操作命令 部件狀態(tài)緩沖器 位置 命令 開始 /停止 處理 機器人命 令 機器人命令文件 操作 設(shè)置 處理活動 記錄機器 人動作 位串 數(shù)據(jù)和控制模型的關(guān)系 DFD 加工規(guī)約
33、 加工模型 DFD 控制規(guī)約 控制模型 數(shù)據(jù)輸出 數(shù)據(jù)條件 數(shù)據(jù)輸入 控制輸入 控制輸出 加工 激活者 SafeHome的控制面板 與用戶 交互 SAFEHOME ARMED POWER 01 1 2 3 4 5 6 7 8 9 * 0 # OFF ARAY STAY MAX TEST BYPASS INSTANT CODE CHIME READY panic alarm check fire away stay instant bypass not ready SafeHome的第 0層 SafeHomede 軟件系統(tǒng) 用戶命令 和數(shù)據(jù) 顯示信息 控制面板 傳感器 狀態(tài) 警告類型 電話號 碼
34、撥音 傳感器 電話線 警鈴 控制面板顯示 SafeHome的第 1層 控制 面板 與用戶 交互 控制 面 板 顯 示 密碼 電話號碼撥音 傳感器狀態(tài) 顯示 信息 配置請求 用戶命令 和數(shù)據(jù) 配置 系統(tǒng) 警 鈴 電 話 線 傳感器 配置信息 顯示信息 和狀態(tài) 監(jiān)控 傳感器 激活不 激活系統(tǒng) 傳感器信息 密碼 處理 警告類型 檢驗 id信息 開始 停止 狀態(tài)信息 監(jiān)控傳感器的第 2層 電話號碼撥音 傳感器狀態(tài) 配置數(shù)據(jù) 顯示格式 配置信息 產(chǎn)生警告 信息 撥號 評估設(shè)置 傳感器信息 讀傳感器 警告類型 傳感器 id類型 傳感器 id 類型定位 SafeHome的第一層 控制面 板 與用戶 交互 控
35、制 面 板 顯 示 顯示活動狀態(tài)( 完成、在處理中 ) 配置 系統(tǒng) 警 鈴 電 話 線 傳感器 配置信息 顯示信息 和狀態(tài) 監(jiān)控 傳感器 激活不 激活系統(tǒng) 警告 信號 密碼 處理 傳感器 事件 警告 狀態(tài) 超 時 閃爍標(biāo)志 開關(guān)切換 狀態(tài)轉(zhuǎn)換圖 (STD) 描述軟件狀態(tài)的變遷,它是在 CSPEC中常用的一種重要 描述工具。( P48) 電梯 狀態(tài)圖舉例 在一樓 上升 停滯 下降 回到一樓 回一樓 想要到 達(dá)樓層 想要到 達(dá)樓層 電梯行程 開始 向上 向上 向下 概念模型和規(guī)范化 用戶的數(shù)據(jù)要求 -需要哪些數(shù)據(jù),數(shù)據(jù)之間有哪些聯(lián)系,數(shù)據(jù)本身有哪些性 質(zhì),數(shù)據(jù)的結(jié)構(gòu) 等)。 用戶的處理要求 -對數(shù)
36、據(jù)進行哪些處理,每個處理的邏輯功能。 概念性模型(信息模型) -一種面向問題的數(shù)據(jù)模型,是按照用戶的觀點來 對數(shù)據(jù)和信息建模。表示概念性數(shù)據(jù)模型的最常用方法是 實體 -聯(lián)系方法 ,采用用 ER圖的方式,這種表示又稱為 ER模型 。 ER模型 實體: 客觀世界中存在的且可區(qū)分的事物。 聯(lián)系: 客觀事物之間的聯(lián)系(三類 -1: 1, 1: N, M:N) 屬性: 實體或聯(lián)系所具有的性質(zhì)。 教師 姓名 性別 職稱 職務(wù) 教師號 教 1 課程 N 課程號 課名 學(xué)時 學(xué)分 學(xué) M 學(xué)生 N 學(xué)號 姓名 性別 系 年級 成績 范式 通常用范式定義消除數(shù)據(jù)的冗余度(略) E-R圖 數(shù)據(jù)及數(shù)據(jù)庫需求 在數(shù)據(jù)
37、詞典中,強調(diào)對數(shù)據(jù)存儲結(jié)構(gòu)的邏輯設(shè)計,并 用數(shù)據(jù)結(jié)構(gòu)表達(dá)數(shù)據(jù)項之間的邏輯關(guān)系。 但任何一個軟件系統(tǒng)都可能有成千上萬個數(shù)據(jù)項,僅 僅描述這些數(shù)據(jù)項是不夠的,更重要的是如何把它們 以最優(yōu)的方式組織起來,以滿足系統(tǒng)對數(shù)據(jù)的要求。 E-R方法 ( Entity-Relationship Approach) 和實體模型 在需求分析階段進行數(shù)據(jù)庫邏輯設(shè)計過程中, 使用 E- R圖,可定義一 個實體模型 。 實體模型是現(xiàn)實世界的純表示 ,它不涉及數(shù)據(jù)世界的 數(shù)據(jù)結(jié)構(gòu)、存取路徑、存取效率等問題。因此,它 可 以轉(zhuǎn)換成數(shù)據(jù)庫中的數(shù)據(jù)模型 。 E-R圖中的基數(shù)表示: 在 E-R圖中,每個 方框 表示 實體型 或
38、屬性 ,方框之間 的 連線 表示 實體之間 ,或 實體與屬性之間的聯(lián)系 。出 現(xiàn)在連線上的短豎線可以看成是“ 1” ,而圓圈隱含 表示“ 0” 。 例如,在教學(xué)管理中,一個教師可以教授零門、一門 或多門課程,每位學(xué)生也需要學(xué)習(xí)幾門課程。因此, 教學(xué)管理中涉及的對象(實體型)有 學(xué)生 、 教師 和 課 程 。 用 E-R圖描述它們之間的聯(lián)系,得下圖。其中,學(xué)生 與課程是多對多的聯(lián)系,而教師與課程的聯(lián)系是零、 一對多。 進一步,要確定屬性。例如, 學(xué)生具有 學(xué)號 、 姓名 、 性別 、 年齡 、 專業(yè) (其它略) 等屬性; 課程具有 課程號 、 課程名 、 學(xué)分 、 學(xué)時數(shù) 等屬性; 教師具有 職
39、工號 、 姓名 、 年齡 、 職稱 等屬性。 此外,學(xué)生通過學(xué)號、分?jǐn)?shù)與課程發(fā)生聯(lián)系。如此可 得教學(xué)實體模型。 教學(xué)實體模型 數(shù)據(jù)庫分析的過程 在需求分析階段進行數(shù)據(jù)庫分析的流程 為開發(fā)一個系統(tǒng)所使用的數(shù)據(jù)庫,在開始分析數(shù)據(jù)庫 的需求前,分析員必須 了解該系統(tǒng)的總目標(biāo)和范圍 。 然后 建立一個完整并高度細(xì)化的信息模型 。 此信息模型應(yīng)包括一個 綜合的數(shù)據(jù)詞典 ,定義所有在 開發(fā)數(shù)據(jù)庫時用到的數(shù)據(jù)項。 接著數(shù)據(jù)庫分析定義數(shù)據(jù)庫的 邏輯特性 和 物理特性 。 用例是幫助分析員和用戶確定系統(tǒng)使用情況的 UML組件; 一組用例就是從用戶的角度出發(fā)如何使用系統(tǒng)的描述; 可認(rèn)為用例是系統(tǒng)的一組使用場景;
40、每個場景描述了一個事件的序列; 每個序列是由一個人、另一個系統(tǒng)、一個硬件設(shè)備或某段時間 的流逝所發(fā)起; 每個發(fā)起事件序列的實體叫做 參與者( actor) 或 行動者 什么是用例( use case)? 用例圖 用例建模 用例建模是用于描述一個系統(tǒng)應(yīng)該做什么的建模技術(shù) 用例建??捎糜谛孪到y(tǒng)的需求獲取,也可用于已有系 統(tǒng)的升級 用例模型( use case model) 一個用例模型可由若干幅用例圖組成 用例描述了用戶和系統(tǒng)之間的交互,其重點是 系統(tǒng)為 用戶做什么 用例模型描述全部的 系統(tǒng)功能行為 一幅用例圖包含的模型元素有: 用例 參與者(行為者、執(zhí)行者) 系統(tǒng) 用例 參與者 系統(tǒng) 參與者 通
41、信 關(guān)系 用例模型表示法 銷售系統(tǒng)用例圖 購買商品 登錄 退貨 收款 員 POS 顧客 購買商品 退貨 商店 顧客 以商店作為系統(tǒng)邊界 以 POS作為系統(tǒng)邊界 POS系統(tǒng)用例圖 購買商品 登錄 退貨 收款 員 POS 顧客 啟動 /關(guān)閉 管理用戶 其他 管理員 系統(tǒng)管理員 參與者與它們所發(fā)起執(zhí)行的過程(簡要描述) 現(xiàn)金結(jié)算 登錄 收款員 退貨 購買商品 顧客 關(guān)閉系統(tǒng) 啟動系統(tǒng) 管理員 增加新用戶 系統(tǒng)管理員 用例描述實例 用例: 購買商品 參與者:顧客(發(fā)起者)、收款員 類型: 主要的 描述: 顧客帶著所要購買商品到付款處,收款員 記錄商品信息并收款。 用例: 啟動 /關(guān)閉系統(tǒng) 參與者:管理
42、員 類型: 主要的 描述: 管理員接通一臺 POS機電源,檢查時間、 日期正確性,檢查完成后,系統(tǒng)處于就緒 狀態(tài),以備收款員使用。 對象關(guān)系圖( Object-Relationship,O-R) 對象關(guān)系圖是由 E-R圖演變而來的。對象通過制定的關(guān)系 和其他對象連接,規(guī)定連接的基數(shù)并建立整體的對象 -關(guān) 系網(wǎng)絡(luò)。 金融機構(gòu)類圖舉例 : 所有人 財產(chǎn) 人員 金融機構(gòu) 信貸銀行 銀行 抵押 本金 利率 到期 * * 有次序的 * * * 借方 債權(quán)人 房 屋 保險機構(gòu)類圖舉例 : 銷售代表 0 . 1 定貨 name address 顧客 creditRating( ):String 產(chǎn)品 雇員
43、1 dataReceived isPrepaid number:String price:Money 協(xié)作顧客 contactName creditRating creditLimit creditCard# 個人顧客 creditRating( ) =“poor” 定貨作業(yè)線 dispatch( ) close( ) remind( ) billForMonth( ) Quantity:Integer price:Money isSatisfied:Boolean 1 * * * * 1 物品 網(wǎng)上商店對象模型 (部分 )示例 (UML) 對象行為圖 對象行為模型用于描述對象動態(tài)行為,通常由
44、對象狀 態(tài)轉(zhuǎn)換圖、事件軌跡圖和事件流圖等來描述。( P52-P53) 電梯 狀態(tài)轉(zhuǎn)換圖 在一樓 上升 停滯 下降 回到一樓 回一樓 想要到 達(dá)樓層 想要到 達(dá)樓層 電梯行程 開始 向上 向上 向下 接電話的的部分事件軌跡圖 : 受話者 交換機 遠(yuǎn)程交換機 受話者 拿起話筒 聽通話聲 撥號碼 . 鈴響信號 鈴響 鈴響停止信號 拿起話筒 鈴響停止 10 d e a b c b-a1 e-d5 c-b10 路徑 文檔打印系統(tǒng)的部分事件流圖 打印機忙 保存打印文件 隊列 計算機 打印機空閑 打印文件 打印機 打印服務(wù)器 打印文件 4、軟件需求說明書 (SRS) (Software Requiremen
45、t Specification) SRS的作用: 開發(fā)者與用戶間事實上的技術(shù)合同書 開發(fā)者下一步設(shè)計和編碼的基礎(chǔ) 測試驗收目標(biāo)系統(tǒng)的依據(jù) 軟件需求說明( SRS) 引言 信息描述 功能描述 行為描述 質(zhì)量保證 接口描述 其他描述 1.需求規(guī)格說明書 2. 編制需求分析階段的文檔 軟件需求說明書 數(shù)據(jù)要求說明書 初步的用戶手冊 修改、完善與確定軟件開發(fā)實施計劃 需求說明書由以下幾部分組成: 一套分層的數(shù)據(jù)流圖 一本數(shù)據(jù)字典 一組小說明 補充材料 常用的分析方法 面向數(shù)據(jù)流 的結(jié)構(gòu)化分析方法 (SA) 面向數(shù)據(jù)結(jié)構(gòu) 的 Jackson方法 (JSD) 面向?qū)ο?的分析方法 (OOA) 等 3.5
46、結(jié)構(gòu)化分析方法 (Structured Analisys, SA) 結(jié)構(gòu)化分析就是使用 DFD,DD,結(jié)構(gòu)化語言,判 定表和判定樹等工具,來建立一種新的,稱為結(jié)構(gòu) 化說明書的目標(biāo)文檔。 結(jié)構(gòu)化分析的基本步驟 : 由頂向下對系統(tǒng)進行功能分解,畫出分層 DF圖; 由后向前定義系統(tǒng)的數(shù)據(jù)和加工,編制 DD, PSPEC; 最終寫出 SRS. 結(jié)構(gòu)化分析方法使用工具: 數(shù)據(jù)流圖 數(shù)據(jù)詞典 結(jié)構(gòu)化英語 判定表與判定樹 描述銀行取款過程的數(shù)據(jù)流圖 畫分層數(shù)據(jù)流圖 軟件工程技術(shù)中,控制復(fù)雜性的兩個基本手段是“分解” 和“抽象”。 分解? 為了將復(fù)雜性降低到人可以掌握的程度,可以把大問題 分割成若干個問題,然
47、后分別解決。 抽象? 分解也可以分層進行,即先考慮問題最本質(zhì)的屬性, 暫把細(xì)節(jié)略去,以后再逐層添加細(xì)節(jié),直至涉及到最 詳細(xì)的內(nèi)容。 DFD可以用來表示一個系統(tǒng)或軟件在任何層次 上的抽象。 較大型軟件系統(tǒng) DFD分成多層 (子圖、 父圖概念 ),可以表示數(shù)據(jù)流和功能的進一步的細(xì)節(jié)。 數(shù)據(jù)流圖的層次結(jié)構(gòu) 為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況,需要采用 層次 結(jié)構(gòu) 的數(shù)據(jù)流圖。按照系統(tǒng)的層次結(jié)構(gòu)進行 逐步分解 ,并以 分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關(guān)系,能清楚地表達(dá)和容易理 解整個系統(tǒng)。 分層的數(shù)據(jù)流圖 在多層數(shù)據(jù)流圖中, 頂層流圖 僅包含 一個加工 ,它代 表被開發(fā)系統(tǒng)。它的輸入流是該系統(tǒng)的輸入數(shù)據(jù),輸
48、 出流是系統(tǒng)所輸出數(shù)據(jù) 底層流圖 是指其 加工不需再做分解 的數(shù)據(jù)流圖,它處 在最底層 中間層流圖 則表示 對其上層父圖的細(xì)化 。它的每一加 工可能繼續(xù)細(xì)化,形成子圖。 結(jié)構(gòu)化分析方法步驟示例 商店業(yè)務(wù)處理系統(tǒng) 這個數(shù)據(jù)流圖只是一個高層的系統(tǒng)邏輯模型,它反映 了目標(biāo)系統(tǒng)要實現(xiàn)的功能 數(shù)據(jù)流圖繪制步驟 首先確定系統(tǒng)的輸入和輸出 根據(jù)商店業(yè)務(wù),畫出頂層數(shù)據(jù)流圖,以反映最主要 業(yè)務(wù)處理流程 經(jīng)過分析,商店業(yè)務(wù)處理的 主要功能 應(yīng)當(dāng)有 銷售 、 采購 、 會計 三大項。 主要數(shù)據(jù)流輸入的源點 和 輸 出終點 是 顧客 和 供應(yīng)商 。 然后從輸入端開始,根據(jù)商店業(yè)務(wù)工作流程,畫 出數(shù)據(jù)流流經(jīng)的各加工框,
49、逐步畫到輸出端,得 到第一層數(shù)據(jù)流圖 第一層數(shù)據(jù)流圖 加細(xì)每一個加工框 銷售細(xì)化 采購細(xì)化 需求分析示例 教材購銷管理系統(tǒng)( 1) 問題描述:學(xué)校教材科根據(jù)業(yè)務(wù)的需要,建 立一個學(xué)校教材購銷管理系統(tǒng),提高教材采 購、銷售和信息管理的效率。 學(xué) 生 張秘書 購書 申請 王會計 李出納 趙保管 學(xué) 生 購書 證明 購書 申請 購書 申請 書 學(xué) 生 審 查 有效性 購書 單 開發(fā)票 開領(lǐng) 書單 發(fā) 書 學(xué) 生 有 效 購書單 發(fā)票 領(lǐng)書 單 書 學(xué) 生 審查并 開發(fā)票 購書 單 開領(lǐng) 書單 發(fā)書 學(xué) 生 發(fā)票 領(lǐng)書單 書 2)去掉具體模型中的非 本質(zhì)因素,抽象出當(dāng)前 系統(tǒng)的邏輯模型 1)通過對現(xiàn)實
50、環(huán)境的調(diào)查研究,獲 得當(dāng)前系統(tǒng)的具體模型 3)分析當(dāng)前系統(tǒng)與目標(biāo) 系統(tǒng)的差別,建立目標(biāo) 系統(tǒng)的邏輯模型。 需求分析示例 教材購銷管理系統(tǒng)( 2) 學(xué) 生 審查并 開發(fā)票 購書單 開領(lǐng) 書單 學(xué) 生 發(fā)票 領(lǐng)書單 無效書單 4)對目標(biāo)系統(tǒng)進行補充 和完善,并寫出完整的 需求說明。 學(xué) 生 1 審查并 開發(fā)票 購書單 2 開領(lǐng) 書單 學(xué) 生 發(fā)票 領(lǐng)書單 無效書單 各班學(xué)生用書表 教材存量表 5)對需求說明進行復(fù)審, 直到確認(rèn)文檔齊全,并 且符合用戶的全部需求 為止 需求分析示例 教材購銷管理系統(tǒng)( 3) 學(xué)生 教材購銷管理系統(tǒng) 書 庫保管員 1. 教材購銷管理系統(tǒng)的頂層 DFD 學(xué)生 書 庫 保
51、管員 2. 第二層 DFD圖 教材購銷系統(tǒng) 購書單 領(lǐng)書單 缺書單 進書通知 購書單 領(lǐng)書單 1 銷 售 2 采購 進書通知 F2: 缺書登記表 F1: 教材存量表 缺書單 進書通知 需求分析示例 教材購銷管理系統(tǒng)( 4) 1.1 審 查 有效性 1.2 開發(fā)票 有效 購書單 1.3 領(lǐng)書并 開領(lǐng)書單 發(fā)票 1.4 登記 缺書 1.5 補售 教材 F2: 缺書登記表 學(xué)生 學(xué)生 無效書單 領(lǐng)書單 領(lǐng)書單 F3: 各班學(xué)生用書表 F4: 售書登記表 補售 書單 暫缺書單 采購 3. 第三層 DFD圖 銷售子系統(tǒng) F1: 教材存量表 需求分析示例 教材購銷管理系統(tǒng)( 5) 2.3 修改教材庫 存和
52、待購量 2.1 按 書 號 匯總?cè)睍?F2: 缺書登記表 銷售 子系統(tǒng) 書庫 保管員 F1: 教材存量表 進書通知 3. 第三層 DFD圖 采購子系統(tǒng) 2.2 按出版社 統(tǒng)計缺書 F5: 待購教材表 F6: 教材一覽表 進書通知 需求分析示例 教材購銷管理系統(tǒng)( 6) 數(shù)據(jù)字典( Data Directory-DD) 領(lǐng)書單 = 學(xué)院 +專業(yè) +班級 +學(xué)號 +姓名 +書號 +書名 +數(shù)量 +日期 有效購書單 = 領(lǐng)書單 發(fā)票 = 學(xué)號 +姓名 +書號 +書名 +單價 +數(shù)量 +總價 +書費合計 教材存量表 = 書號 +單價 +數(shù)量 暫缺書單 = 學(xué)號 +姓名 + 書號 +數(shù)量 補售書單 =
53、學(xué)號 +姓名 + 書號 +數(shù)量 書 號 書 名 數(shù) 量 書 號 書 名 數(shù) 量 學(xué)院: 專業(yè): 班級: 學(xué)號: 姓名: 武漢科技大學(xué)教材科領(lǐng)書單 20 年 月 日 書號 書名 單價 數(shù)量 金額 備注 學(xué)號: 姓名: 發(fā) 票 人事工資管理系統(tǒng)的頂層 DFD(概圖 )范例 人 事 部 門 人事工資 管理系統(tǒng) 會 計 部 門 職 工 職工基本 信息管理 子系統(tǒng) 1.0 2.0 人事工資管理系統(tǒng) 0層 DFD范例 職工出缺勤信息 職工工資管理 子系統(tǒng) 3.0 職工出缺 勤管理 子系統(tǒng) 職工基本信息 職工工資信息 人 事 部 門 會 計 部 門 職 工 建立職工 出缺勤信息 3.1 人事工資管理系統(tǒng) 1
54、層 DFD:加工 3.0的分解圖 職工出缺勤信息 3.2 制作職工出缺 勤信息 統(tǒng)計表 職工基本信息 實例 考務(wù)處理系統(tǒng)功能 (1)對考生送來的報名單進行檢查; (2)對合格的報名單編好準(zhǔn)考證號后將準(zhǔn)考證送給考生,并將匯總 后的考生名單送給閱卷站; (3)對閱卷站送來的成績單進行檢查,并根據(jù)考試中心制定的合格 標(biāo)準(zhǔn)審定合格者; (4)制作考生通知單 (含成績及合格 /不合格標(biāo)志 )送給考生; (5)按地區(qū)進行成績分類統(tǒng)計和試題難度分析,產(chǎn)生統(tǒng)計分析表。 頂層數(shù)據(jù)流圖 考 生 考務(wù) 處理系統(tǒng) 考 試 中 心 閱卷站 不合格報名單 報名單 準(zhǔn)考證 考生通知單 成 績 清 單 合格標(biāo)準(zhǔn) 錯誤成績 清
55、單 考 生 名 單 統(tǒng)計分析表 二層 數(shù)據(jù)流 圖 登記 報名單 報名單 準(zhǔn)考證 1 統(tǒng)計成績 2 不合格 報名單 考生通知 單 成 統(tǒng)計分析 表 考生名冊 績 清 單 合 格 標(biāo) 準(zhǔn) 考 生 名 單 成 績 清 單 錯 誤 三層數(shù)據(jù)流圖 (a) 檢查 報名單 報名單 準(zhǔn)考證 1.1 編準(zhǔn)考證號 1.2 不合格 報名單 考生名冊 考生名單 合格 報名單 登記 考生 1.3 三層數(shù)據(jù)流圖 (b) 檢查 成績清單 2.1 審定 合格者 2.2 考生名冊 正確 成績清單 制作 通知單 2.3 分析 統(tǒng)計成績 2.4 分析 試題難度 2.5 試題得分清單 考生 通知單 難度 分析表 合格 標(biāo)準(zhǔn) 分類 統(tǒng)
56、計表 成績清單 錯誤 成績清單 經(jīng)審定的 成績清單 檢查和修改數(shù)據(jù)流圖的原則 數(shù)據(jù)流圖上所有圖形符號 只限于 前述四種基本圖形元 素; 數(shù)據(jù)流圖的 主圖必須包括前述四種基本元素 ,缺一不 可; 數(shù)據(jù)流圖的主圖上的數(shù)據(jù)流必須封閉在外部實體之間; 每個加工 至少有一個輸入數(shù)據(jù)流和一個輸出數(shù)據(jù)流; 在數(shù)據(jù)流圖中,需 按層給加工框編號 。編號表明該加 工所處層次及上下層的親子關(guān)系; 規(guī)定任何一個數(shù)據(jù)流子圖必須與它上一層的一個加工 對應(yīng),兩者的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流必須一致。此 即 父圖與子圖的平衡; 可以在數(shù)據(jù)流圖中加入物質(zhì)流,幫助用戶理解數(shù)據(jù)流 圖; 圖上每個元素都必須有名字; 數(shù)據(jù)流圖中不可夾帶控
57、制流; 初畫時可以忽略瑣碎的細(xì)節(jié),以集中精力于主要數(shù)據(jù)流。 畫分層 DFD的指導(dǎo)原則 (1) 父圖與子圖的 平衡 模型細(xì)化時必須保持?jǐn)?shù)據(jù)流的連 續(xù)性,即每個細(xì)化部分的輸入和輸出 必須保持不變 (父圖和子圖輸入數(shù)據(jù) 和輸出數(shù)據(jù)應(yīng)一致 )。 父圖與子圖平衡的特例 領(lǐng) 書 單 1.3 發(fā)票 1.3.3 1.3.2 教材 1.3.1 學(xué)生 領(lǐng) 書 單 父圖 子圖 發(fā)票學(xué)生教材 (2) 區(qū)分局部文件和局部外部項 .1 .2 .3 1 父圖 子圖 畫分層 DFD的指導(dǎo)原則 (3) 遵守加工的編號原則 子圖的編號為父圖中相應(yīng)加工的編號; 子圖中加工的編號由子圖號、小數(shù)點、局部號連接而成。 畫分層 DFD的指
58、導(dǎo)原則 畫分層 DFD的指導(dǎo)原則 (4) 分解的深度與層次 按功能情況定,一般設(shè)深度為 3-5。 原則: 分解應(yīng)自然,概念上合理、清晰; 只要不影響數(shù)據(jù)流圖的“易理解性”,可以適當(dāng)?shù)囟喾纸獬蓭撞糠郑@樣 分層土的層數(shù)就可少些; 一般說來,在上層可以分解的快些,而在下層則應(yīng)分解的慢些,因為上層 是一些綜合性的描述,“易理解性”相對地說不太重要。 實例:運動會管理系統(tǒng) 過程如下: 首先決定日期、地點規(guī)模設(shè)立那些比賽項目、報名 期限等,并作出一些規(guī)定,如每人最多可參加多少項 目,每個項目每隊最多可有多少人參加等。在報名結(jié) 束后,要給每個運動員編號,統(tǒng)計每個項目有多少運 動員以及有哪些運動員參加,并根
59、據(jù)每個項目的參加 人數(shù)等具體情況派出比賽日程表。在運動會進行過程 中要按各項比賽的成績及時公布單項名次并累計團體 總分。比賽全部結(jié)束后要公布團體名次。 3.6 面向?qū)ο蠓治龇椒?思考題 軟件開發(fā)中為什么要使用面向?qū)ο?方法? 面向?qū)ο蠓治龇椒ㄅc結(jié)構(gòu)化分析方 法有哪些相似之處?有何區(qū)別? 面向?qū)ο蠓椒ㄊ菍^去的一個完全 突破,還是“換湯不換藥”? 開發(fā)方法的組合 分析 設(shè)計 編程 結(jié)構(gòu)化 結(jié)構(gòu)化 面向?qū)ο?結(jié)構(gòu)化 面向?qū)ο?面向?qū)ο?面向?qū)ο?結(jié)構(gòu)化 第三代或第四代語言 面向?qū)ο?面向?qū)ο?第三代或第四代語言 面向?qū)ο?面向?qū)ο?傳統(tǒng)編程與面向?qū)ο蟮幕旌?面向?qū)ο?面向?qū)ο?面向?qū)ο?傳統(tǒng)方法數(shù)
60、據(jù)與過程是分離的 過程 1 輸入 輸出 過程 2 過程 3 數(shù)據(jù)實體 屬于該對象 的數(shù)據(jù) 對象 處理數(shù)據(jù)的方法 消息 消息 對象把數(shù)據(jù)和處理數(shù)據(jù)的方法封裝成一個單元 傳統(tǒng)方法和面向?qū)ο蠓椒ǖ谋容^ 傳統(tǒng)方法 系統(tǒng)是過程的集合 過程與數(shù)據(jù)實體交互 過程接受輸入并產(chǎn)生輸出 面向?qū)ο蠓椒?系統(tǒng)是交互對象的集合 對象與人或其它對象交互 對象發(fā)送與響應(yīng)消息 傳統(tǒng)系統(tǒng)分析方法 :面向功能 ,把系統(tǒng)看成一組功能; OOA方法 :把問題當(dāng)作一組相互作用的實體,并確定實體 間關(guān)系。 傳統(tǒng)方法和面向?qū)ο蠓椒ǖ谋容^ 結(jié)構(gòu)化分析 (傳統(tǒng)建模方法 )方法 分析模型: 數(shù)據(jù)流圖 (DFD) 數(shù)據(jù)字典 (DD) 小說明 E-
61、R圖 (ERD) 狀態(tài)變遷圖 (STD) 面向?qū)ο蠓治龇椒?分析模型: 用例模型(用況模型) 對象模型(概念模型) 功能模型(行為模型) 分析建模方法與分析模型 分析模型的主要目標(biāo) 描述用戶需要 建立創(chuàng)建軟件設(shè)計的基礎(chǔ) 定義軟件完成后可被確認(rèn)的一組需求 OO方法的開發(fā)過程 OO方法改進了在生存期各個階段間的界面 , 因為生存期各個階段開發(fā)出來的 “ 部件 ” 都是 類 , 在面向?qū)ο笊嫫诘母鱾€階段對各個 類 的信息進 行細(xì)化 , 類 成為分析 、 設(shè)計和實現(xiàn)的 基本單元 。 用例建模 用例建模是用于描述一個系統(tǒng)應(yīng)該做什么的建模技術(shù); 用例建??捎糜谛孪到y(tǒng)的需求獲取,也可用于已有系 統(tǒng)的升級。
62、 發(fā)現(xiàn)角色( P61) 通過回答下列問題,可以幫助建模者發(fā)現(xiàn)角色 使用系統(tǒng)主要功能的人是誰? 需要借助于系統(tǒng)完成日常工作的人是誰? 誰來維護、管理系統(tǒng),保證系統(tǒng)正常工作? 系統(tǒng)控制的硬件設(shè)備有哪些? 系統(tǒng)需要與哪些其它系統(tǒng)交互? 對系統(tǒng)產(chǎn)生的結(jié)果感興趣的人或事是哪些? 發(fā)現(xiàn)用例( P61) 詢問以下問題 角色需要從系統(tǒng)中獲得哪種功能?角色需要做什么? 角色需要讀取、產(chǎn)生、刪除、修改或存儲系統(tǒng)中的信息嗎? 系統(tǒng)中發(fā)生的事件需要通知角色嗎? 如果用系統(tǒng)的新功能處理角色的日常工作是簡化了還是提 高了工作效率? 用例模型( use case model) 一個用例模型可由若干幅用例圖組成 用例描述了用
63、戶和系統(tǒng)之間的交互,其重點是系 統(tǒng)為用戶做什么 用例模型描述全部的 系統(tǒng)功能行為 一幅用例圖包含的模型元素有: 用例 參與者(行為者、執(zhí)行者) 系統(tǒng) 用例 參與者 系統(tǒng) 參與者 通信 關(guān)系 用例模型 用例圖舉例 簽定一份 保險單 客戶 保險銷 售人員 銷售統(tǒng)計 客戶統(tǒng)計 2.領(lǐng)域分析 目的:發(fā)現(xiàn)或創(chuàng)建一些可廣泛應(yīng)用的類,使它們可以被復(fù)用。 具體地說,面向?qū)ο箢I(lǐng)域分析就是以公共對象、類、子集合和框架等形 式,在特定的應(yīng)用領(lǐng)域中表示、分析和規(guī)約公共的可復(fù)用的能力。舉 例: ( P63) 領(lǐng)域分析的輸入輸出 領(lǐng)域知識源 領(lǐng)域分析 領(lǐng)域分析 -創(chuàng)建可以廣泛地用于整個應(yīng)用領(lǐng)域范疇的可復(fù)用類 (構(gòu)件 )
64、航空 銀行 電子設(shè)備 多媒體視頻 領(lǐng)域 分析 領(lǐng)域 分析 模型 技術(shù)文件 已有應(yīng)用 客戶評定 專家建議 需求 提取類 復(fù)用標(biāo)準(zhǔn) 模型 語言 領(lǐng)域分析活動: 定義被調(diào)查的領(lǐng)域,相關(guān)的設(shè)計、規(guī)約、代碼、政策、標(biāo)準(zhǔn)、規(guī)程等項 對領(lǐng)域中提取的項,劃分種類并提取模式,命名,并且分層。 收集領(lǐng)域中應(yīng)用的代表性樣本 分析每個樣本中的應(yīng)用,標(biāo)識對象、說明理由、定義適應(yīng)性、估算復(fù)用率等 開發(fā)對象分析模型,作為設(shè)計和構(gòu)造類的基礎(chǔ) 3.類 /對象建模 系統(tǒng)的用例一旦確定,即可開始標(biāo)識類 對象。 考察系統(tǒng)的使用實例,首先將這些實例中的名詞 或名詞短語匯總起來,得到候選對象;然后考察這些對象的特征, 進而確定哪些對象應(yīng)
65、該包含在分析模型中。舉例: ( P64) 對象模型 是三個模型中最關(guān)鍵的一個模型 , 它的作用是 描述系 統(tǒng)的靜態(tài)結(jié)構(gòu) , 包括 構(gòu)成系統(tǒng)的類和對象 , 它們的屬 性和操作 , 及 它們之間的關(guān)系 。 確定需求分析模型中的類 /對象 對象( object) 現(xiàn)實世界中某個具體的物理實體或概念在計算機 邏輯中的映射和體現(xiàn)。 對象具有的含義: 在現(xiàn)實世界中: 是客觀世界中的一個實體 在面向?qū)ο蟪绦蛑校?表達(dá)成計算機可理解、可操縱的對象 在計算機世界中: 是一個可標(biāo)識的存儲區(qū)域 識別概念 候選概念類型 舉例 物理的或?qū)嵲诘膶ο?POS機 飛機 規(guī)格說明、設(shè)計或事物 描述 產(chǎn)品規(guī)格說明 航班描述 地點
66、 商店 機場 事務(wù) 銷售、支付、在線銷售項 預(yù)定 人的角色 出納員 飛行員、乘客 系統(tǒng)外部的其他系統(tǒng)或 設(shè)備 信用卡授權(quán)系統(tǒng) 空中交通控制系統(tǒng) 組織 銷售部 建立概念模型( UML中的類圖) 確定并定義類 建立關(guān)聯(lián) 添加屬性 描述系統(tǒng)行為:系統(tǒng)順序圖等 類及對象間常見的聯(lián)系 分類關(guān)系 (歸納關(guān)系、一般與特殊的關(guān)系) 組成關(guān)系 (組合關(guān)系、整體 /部分的關(guān)系) 對象屬性之間的靜態(tài)的聯(lián)系 對象行為的動態(tài)聯(lián)系 定義類的結(jié)構(gòu)與層次 分類關(guān)系 (一般與特殊的關(guān)系 )示例 學(xué)生 本科生 研究生 分類結(jié)構(gòu)(一般 /特殊結(jié)構(gòu)) 分類是對象抽象的基礎(chǔ) 分類結(jié)構(gòu)表現(xiàn)的是事物的一般與特殊的關(guān)系,即“ is-a” 關(guān)系。 面向?qū)ο笮g(shù)語中常把一般與特殊的關(guān)系稱為 泛化 ( Generalization) 與 特化( Specialization) 聯(lián)系 存戶 一般 /特殊結(jié)構(gòu)舉例 一般類 (父類、基類、超類 ) 特殊類 (子類、具體類 ) 繼承 一個特殊類中的所有對象可繼承一般類中的屬性、服 務(wù)、關(guān)系 賬號 姓名 余額 存款 取款 支票存戶 儲蓄存戶 利息率 組成關(guān)系 (整體與部分的關(guān)系 )示例 學(xué)科部 辦公室
- 溫馨提示:
1: 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
2: 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
3.本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
5. 裝配圖網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 市教育局冬季運動會安全工作預(yù)案
- 2024年秋季《思想道德與法治》大作業(yè)及答案3套試卷
- 2024年教師年度考核表個人工作總結(jié)(可編輯)
- 2024年xx村兩委涉案資金退還保證書
- 2024年憲法宣傳周活動總結(jié)+在機關(guān)“弘揚憲法精神推動發(fā)改工作高質(zhì)量發(fā)展”專題宣講報告會上的講話
- 2024年XX村合作社年報總結(jié)
- 2024-2025年秋季第一學(xué)期初中歷史上冊教研組工作總結(jié)
- 2024年小學(xué)高級教師年終工作總結(jié)匯報
- 2024-2025年秋季第一學(xué)期初中物理上冊教研組工作總結(jié)
- 2024年xx鎮(zhèn)交通年度總結(jié)
- 2024-2025年秋季第一學(xué)期小學(xué)語文教師工作總結(jié)
- 2024年XX村陳規(guī)陋習(xí)整治報告
- 2025年學(xué)校元旦迎新盛典活動策劃方案
- 2024年學(xué)校周邊安全隱患自查報告
- 2024年XX鎮(zhèn)農(nóng)村規(guī)劃管控述職報告