碩士論文寫作范本-結構化方法

1、分類號 tp31 密級 公開udc 編號碩士研究生學位論文題目 xx 系統(tǒng)的分析與設計學院（所、中心）軟件學院專業(yè)名稱軟件工程研究生姓名 學號導師姓名 職稱云南大學碩士研究生論文xx系統(tǒng)的分析與設計獨創(chuàng)性聲明本人聲明所呈交的論文是我個人在導師指導下進行的研究工作及取得的研究成果。除了文中特別加以標注和致謝的地方外， 論文中不包含其他人或集體已 經發(fā)表或撰寫過的研究成果，對本文的研究做出貢獻的集體和個人均已在論文中 作了明確的說明并表示了謝意。研究生簽名： 日期：論文使用和授權說明本人完全了解云南大學有關保留、使用學位論文的規(guī)定，即：學校有權保 留并向國家有關部門或機構送交學位論文和論文電子版；

2、允許論文被查閱或借 閱；學?？梢怨颊撐牡娜炕虿糠謨热荩梢圆捎糜坝?、縮印或其他復制手 段保存論文。（保密的論文在解密后應遵循此規(guī)定）研究生簽名： 導師簽名： 日 期： 本人及導師同意將學位論文提交至清華大學“中國學術期刊（光盤版）電子雜志社”進行電子和網絡出版，并編入 cnki系列數據庫，傳播本學位論文 的全部或部分內容，同意按中國優(yōu)秀博碩士學位論文全文數據庫出版章程 規(guī)定享受相關權益。研究生簽名： 導師簽名： 日 期： 摘要簡單的論文總體描述論文首先介紹了 xx系統(tǒng)的研究背景，對所需要解決的問題進行了概述， 討論了項目的研究意義與重要性，闡述了系統(tǒng)開發(fā)方法和相關技術；論文提出了 系統(tǒng)的設

3、計目標，對系統(tǒng)進行了詳細的需求分析，包括業(yè)務需求分析、功能需求分析、數據需求分析和非功能需求分析，給出了系統(tǒng)的業(yè)務流程圖、數據流圖、 功能數據分析圖（ipo圖），并進行了數據字典描述；在系統(tǒng)設計中，對系統(tǒng)進 行了總體設計與模塊設計，給出了系統(tǒng)總功能結構圖 （h圖），包括xx等功能模 塊，分別給出了具體模塊設計的功能結構圖（h圖）、ipo表、和處理流程圖， 詳細闡述了設計內容，并使用實體關系e-r圖和數據庫表結構對數據庫進行了詳 細設計；論文最后對研究的內容進行了總結，闡述了本人的主要工作，指出了論文存在的不足，并對進一步的工作進行了展望。關鍵詞：xxxx ; xxxx; xxxx;abstra

4、ct此處插入英文摘要，就是中文摘要的正確翻譯，注意關鍵詞的翻譯要準 確keywords: 英文關鍵詞，要與中文摘要對應，例如：xxxx; xxxx; xxxx;目錄此處插入論文目錄第一章 引言1.1 項目背景與問題概述1.1.1 項目背景隨著科學技術的進步和社會經濟的發(fā)展，信息化進程已經成為一種必然的趨 勢。近年來，由于信息化在多個領域取得了巨大的成就，為國家的經濟建設和社會發(fā)展做出了不可估量的貢獻。因此，人們認識到，作為國家信息化和社會信息 化的重要組成部分之一的商業(yè)信息化，已然成為了促進社會經濟發(fā)展的一個增長 點，也是推動商業(yè)發(fā)展的重要手段。商業(yè)信息化已經被越來越多的企業(yè)和商家所 關注。網

5、上購物最早在美國出現，1995年美國網上商店亞馬遜開業(yè)(a), 美國第一家安全網絡銀行(first security b)實現網上支付。而我國的網 上購物系統(tǒng)發(fā)展相對較晚，在1998年，中國的第一筆網上交易成功，1999年隨 著8848等b2c網站的正式開通，中國開始進入購物網站的實際階段。從起步到 現在，十多年來網上購物發(fā)展迅速，在1998年，國內最大的商務拍賣網站易趣開 始運行。在1999年b2c網站當當投入運營，2000年卓越成立，到2003年b2b 網站阿里巴巴投資成立了 c2c網站淘寶。網上購物的商家越來越多，同時網上 購物的消費者數量也在迅速的發(fā)展與

6、增長。截止到2005年上半年，我國的上網人數達到1.03億，其中網上購物者達到2000萬人，網上支付的比例增長到近半 數，網上購物成交額已經累計達100億元。在長達6年的網上購物市場發(fā)展過程 中，網上購物者漸漸開始接受并習慣新的購物消費方式，隨著網民人數增加，網上購物者人數有進一步擴大的趨勢。世界電子商務的快速度發(fā)展，同時 b2b、b2c、c2c等一系列的結構快速度 發(fā)展，這些都需要網上商城來支持， 少則自己開個商店，大則阿里巴巴等電子商務，這些都成就了商城系統(tǒng)的出現，正因為網上電子商務的安全性與穩(wěn)定性的要 求高，所以對商城系統(tǒng)也需要有一個嚴格的考驗。不少商家、公司只制作一個或幾個產品介紹的頁

7、面，要修改資料， 需要對網頁重新修改，客戶卻又不能在線下 定單，需要通過多種步驟才能與商家取得聯(lián)系， 其弊端是顯見的，首先是低效率、 數據的嚴重冗余，其次是維護困難。顯然由這些簡單鏈接的頁面構成的網站在數 據的共享性、人機的交互性以及網站維護性上都是很現實的問題。開發(fā)一個基于web的動態(tài)網上購物系統(tǒng)，對發(fā)展電子商務無疑是十分迫切的。1.1.2 問題概述此處插入論文的論點，旨在突出論文討論解決的問題。在信息技術日新月異的今天，隨著新技術、新功能的演變，開發(fā)一個xxx系統(tǒng)有著多種技術手段來實現。如何根據具體需求采用合適的技術來實現，是很 多軟件開發(fā)者正在考慮的問題。展開敘述一些傳統(tǒng)技術手段存在的問

8、題 止匕外，現有的電子商務系統(tǒng)普遍存在著 .問題，一直得不到解決。展開敘述一些傳統(tǒng)網上購物系統(tǒng)普遍存在的問題 1.2 研究的意義和重要性1.2.1 研究的意義此處插入論文的研究意義，應該和 1.1.2小節(jié)的問題概述相呼應1.2.2 研究的重要性此處插入研究的重要性，應該和 1.1.2小節(jié)的問題概述相呼應1.3 研究的內容和主要工作1.3.1 研究的內容此處插入研究的內容，也應該和 1.1.2小節(jié)的問題概述相呼應，簡要說明論文 中的系統(tǒng)采用了什么樣的技術手段， 采用了什么樣的組織架構，做了些什么研究 工作，解決了哪些問題1.3.2 本人主要工作此處插入作者本人在項目中所負責或者完成的具體工作，應

9、與1.3.1的研究內容相對應，簡述作者本人所做的研究工作。止匕外，如果論文所述項目為集體合作， 則應該簡略指出作者本人所負責的工作。以下為范本！在此項目中，本人做了如下工作： 此處插入所做工作在項目開發(fā)中，本人主要負責系統(tǒng)需求分析、功能性分析、系統(tǒng)整體數據庫 設計、主體框架設計搭建、web端程序開發(fā)，系統(tǒng)文檔撰寫、系統(tǒng)整體測試以 及歷史數據導入等工作。1.4 論文結構此處插入該論文的整體結構，簡述論文的整體形式結構，并簡述每一章的主旨。以下為范本，請勿照搬！ 本文由五章內容組成，其中：第一章介紹了本文的研究背景，對所需要解決的問題進行了概述，討論了 項目的研究意義與重要性，闡述了論文的主要內容

10、以及本人的主要工作。第二章闡述的是本文所涉及到的開發(fā)方法及相關技術，包括：軟件工程開 發(fā)模型、結構化建模技術、數據庫技術等。第三章是本文的核心內容之一，針對系統(tǒng)的業(yè)務需求、功能需求、數據需 求和非功能需求等進行了詳細分析， 給出了主要的業(yè)務流程圖和數據流圖， 并利 用數據字典進行了詳細的描述，同時利用 ipo圖進行了功能數據分析。第四章是本文的重點，在進行了系統(tǒng)總體設計的基礎上，采用功能結構圖、 ipo表、核心處理流程圖等對系統(tǒng)的子模塊進行了功能性詳細設計，同時通過實 體e-r圖和數據庫表結構對數據庫進行了詳細設計。第五章總結了本文所做的工作，同時對進一步的工作進行了展望。第二章系統(tǒng)的開發(fā)方法

11、及相關技術本xxx系統(tǒng)采用基于xxx架構，對應使用xxx技術來展現其表示層，分 別對不同需求的用戶服務，旨在最大程度滿足不同用戶的需求。服務層采用xxx 技術來提供統(tǒng)一接口，降低其與其他系統(tǒng)間的耦合度，提供安全數據通信，提高 系統(tǒng)可擴展性、兼容性以及集成能力。 c止匕外，系統(tǒng)采用增量模型進行開發(fā)，以應對不斷變化的需求，大量降低項目 風險，保證系統(tǒng)核心功能，較快的交付可使用的模塊。2.1 軟件工程開發(fā)模型2.1.1 傳統(tǒng)瀑布模型瀑布,k型（也稱為線性順序模型），由溫斯頓羅伊斯在1970年提出，在20 世紀80年代以前，瀑布模型一直都是唯一被廣泛采用的軟件開發(fā)模型。這個模 型中，軟件生命周期中的制

12、訂計劃，需求分析，軟件設計，程序編寫，軟件測試 和運行維護依次由上至下順序展開，如同瀑布流水，逐級下落， 最終得到軟件產 品。理想化的瀑布模型是單邊逐一而下的，認為人在工作過程中不可能犯錯誤。 實際的瀑布模型是帶有反饋逐一而下的， 當后一階段發(fā)現前一階段的錯誤時， 可 以修正前一階段的錯誤繼續(xù)完成后一階段的任務促進軟件開發(fā)工程化，為項目提供了按階段劃分的檢查點降低軟件開發(fā)的復雜度，當前一階段完成后，只需去關注后續(xù)階段可以在增量模型中使用瀑布模型瀑布模型的缺點：缺乏靈活性不適應用戶需求的變化，項目的各個階段之間極少有反 饋如果軟件需求不明確或者經常變更需求，最終可能導致開發(fā)出的軟 件與用戶預期的

13、軟件不符，往往會導致大量的返工，有時甚至會給 開發(fā)人員帶來災難性的后果，而這一點又常常在項目生命期的后期 才有所覺察。2.1.2 改進的螺旋模型螺旋模型由巴利玻姆于1988年正式發(fā)表了軟件系統(tǒng)開發(fā)的“螺旋模型”， 它是將瀑布模型與演化模型相結合， 并且增加了兩者所忽略的風險分析， 彌補了 兩者的不足之處，該模型通常用來指導大型軟件項目的開發(fā)軟件項目的開發(fā)， 。 軟件風險是任何軟件開發(fā)項目中都普遍存在的實際問題， 項目越大，軟件越復雜， 承擔該項目所冒的風險也越大。軟件風險駕馭的目標主要是在造成危害之前及時對風險進行識別，分析，采取對策進而消除或者減少風險的損害。螺旋模型將開 發(fā)劃分為制訂計劃，

14、風險分析，實施工程，客戶評估四類活動。沿著螺旋線每旋轉一圈，表示開發(fā)出一個更完善的新的軟件版本，如果開發(fā)風險過大，開發(fā)機構和客戶無法接受，項目就有可能就此終止。多數情況下，會沿著螺旋線繼續(xù)下去， 自內向外逐步延伸，最終得到滿意產品。螺旋模型開發(fā)的成敗很大程度上依賴于 風險評估的成敗。沿著螺旋線旋轉，在笛卡爾坐標的四個象限上分別表達了四類活動：制定計劃：確定軟件目標，選定實施方案，弄清項目開發(fā)的限制條件。風險分析：分析所選方案，考慮如何識別和消除風險。實施工程：實施軟件開發(fā)?？蛻粼u估：評價軟件功能和性能，提出修改建議。風陶分析制j定h刎方案用限制評價方案、 識別咫險、色險分析:可運行縫0廣f 麻

15、泵/時埠洋摑設計實施l程客戶訐估圖2.2螺旋模型螺旋模型的優(yōu)點：設計上的靈活性，可以在項目的各個階段進行變更。以小的分段來構建大型系統(tǒng)，使成本計算變得簡單容易?？蛻羰冀K參與每個階段的開發(fā)，保證了項目不偏離正確方向以及項目 的可控性。隨著項目推進，客戶始終掌握項目的最新信，從而他或她能夠和管理層有效地交互?？蛻粽J可這種公司內部的開發(fā)方式帶來的良好的溝通和高質量的產 品。螺旋模型的缺點：很難讓用戶確信這種演化方法的結果是可以控制的。建設周期長，而軟件技術發(fā)展比較快，所以經常出現軟件開發(fā)完畢 后，和當前的技術水平有了較大的差距，無法滿足當前用戶需求。2.1.3 面向對象的噴泉模型在面向對象的方法中，

16、提出了于瀑布模型相對應的噴泉模型，該模型的主 要特點是認為軟件生命周期的各個階段是相互重疊和多次反復的，它是一種以用戶需求為動力，以對象為驅動的模型，主要用于描述面向對象的軟件開發(fā)過程。 噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動， 設計活動結 束后才開始編碼活動。該模型的各個階段沒有明顯的界限， 開發(fā)人員可以同步進 行開發(fā)。具優(yōu)點是可以提高軟件項目開發(fā)效率，節(jié)省開發(fā)時間，適應于面向對象的軟件開發(fā)過程。由于噴泉模型在各個開發(fā)階段是重疊的， 因此在開發(fā)過程中需 要大量的開發(fā)人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔， 使得審核的難度加大，尤其是面對可能隨時加入各種信

17、息、需求與資料的情況。噴泉一詞本身就體現了迭代和無間隙的特性。圖2.3噴泉模型1噴泉模型的優(yōu)點：軟件項目開發(fā)效率高，節(jié)省開發(fā)時間，適應于面向對象 的軟件開發(fā)過程。噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計 活動，設計活動結束后才開始編碼活動。 該模型的各個階段沒有明顯的界限， 開 發(fā)人員可以同步進行開發(fā)。噴泉模型的缺點：由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過 程中需要大量的開發(fā)人員，因此不利于項目的管理。此外這種模型要求嚴格管理 文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的 情況。形式化方法模型包含了一組活動，他們導致了計算機軟件的數學規(guī)約。形

18、式化方法使得軟件工程師們能夠通過應用一個嚴格的數學符號體系來規(guī)約、開 發(fā)、和驗證基于計算機的系統(tǒng)。在開發(fā)中使用形式化方法時，它們提供了一種機 制，能夠消除使用其它軟件過程模型難以克服的很多問題。二義性、不完整性、 不一致性能被更容易地發(fā)現和糾正， 而不是通過專門的評審，是通過對應用的數 學分析。形式化方法提供了可以產生無缺陷軟件的承諾。2.2 結構化設計方法2.2.1 結構化方法要素結構化設計方法是基于模塊化、自頂向下細化、結構化程序設計等程序設 計技術基礎發(fā)展起來的。具基本思想是：將軟件設計成由相對獨立且具有單一功 能的模塊組成的結構。結構化設計是數據模型和過程模型的結合。在設計過程中，它從

19、整個程序 的結構出發(fā)，利用模塊結構圖表述程序模塊之間的關系。 結構化設計的步驟如下：評審和細化數據流圖；確定數據流圖的類型；把數據流圖映射到軟件模塊結構，設計出模塊結構的上層；基于數據流圖逐步分解高層模塊，設計中下層模塊；對模塊結構進行優(yōu)化，得到更為合理的軟件結構；描述模塊接口。結構化設計的目的主要是使程序的結構盡可能反映要解決的問題的結構。在軟件設計與開發(fā)中，結構化設計工作是以需求分析階段的成果之一的“數據流圖”為主要依據，進一步推導出軟件的“系統(tǒng)功能結構圖”。2.2.2 結構化方法中常用的設計圖 業(yè)務流程圖業(yè)務流程圖是一種描述系統(tǒng)內各單位、人員之間業(yè)務關系、作業(yè)順序和管理信息

20、流向的圖表，利用它可以幫助分析人員找出業(yè)務流程中的不合理流向，它是物理模型。業(yè)務流程圖主要是描述業(yè)務走向，以業(yè)務處理過程為中心，一般沒有數據的概念。業(yè)務流程圖的元素：流程：流程是獲取一種或多種輸人并且創(chuàng)造一種對客戶有價值的輸出的 一系列活動的集合；決策：用來表示選擇流程流向的控制節(jié)點，表示對問題判斷或判定（審 核/審批/評審）環(huán)節(jié)；開始/結束：表示一系列流程開始或結束的控制節(jié)點；文檔：以文字或圖示描述的內容；數據：數據是具有一定意義的數字、字母、符號和模擬量等的通稱； 數據庫：所有的信息（數據事實等）的匯集的載體。 數據流圖數據流圖（dfd）是一種圖形化技術，它描繪信息流和數據從

21、輸入移動到輸出 的過程中所經受的變換。在數據流圖中沒有任何具體的物理部件， 它只是描繪數 據在軟件中流動和被處理的邏輯過程。 數據流圖是系統(tǒng)邏輯功能的圖形表示，即使不是專業(yè)的計算機技術人員也容易理解它。它是分析員與用戶之間極好的通信 工具，也是今后進行軟件設計的很好的出發(fā)點。為了表達數據處理過程的數據加工情況，需要采用層次結構的數據流圖。按照系統(tǒng)的層次結構進行逐步分解， 并以分層的數據流圖反映這種結構關系，能清楚地表達和容易理解整個系統(tǒng)在多層數據流圖中，頂層流圖僅包含一個加工，它代表被開發(fā)系統(tǒng)。它 的輸入流是該系統(tǒng)的輸入數據，輸出流是系統(tǒng)所輸出數據底層流圖是指其加工不需再做分解的數據流圖，它處

22、在最底層 中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續(xù)細化， 形成子圖。 數據字典數據詞典與數據流圖配合，能清楚地表達數據處理的要求。數據字典以詞條 描述的形式予以展現，對于在數據流圖中每一個被命名的圖形元素，均加以定義, 其內容有：名字、別名或編號、分類、描述、定義、位置、其它等。 hipo 圖hipo圖是舊m公司于70年代中期在層次結構圖的基礎上推出的一種描述 系統(tǒng)結構和模塊內部處理功能的工具（技術）。很適于在自頂向下設計軟件的過 程中使用。一個完整的 hipo圖包含兩個部分：h圖（即層次圖）和ipo圖。 層次圖用于表示一個系統(tǒng)自頂向下的功能模塊層次

23、結構；ipo圖來描述每個模塊 的輸入、輸出及其要執(zhí)行的過程，是對每個模塊進行詳細設計的工具，它能夠方 便地描繪輸入數據、對數據的處理和輸出數據之間的關系。hipo圖由三個基本圖表組成，進行模塊層次功能分解遵循以下步驟： 總體ipo圖：它是數據流程圖的初步分層細化結果，根據數據流程圖， 將最高層處理模塊分解為輸入、處理、輸出三個功能模塊。hipo圖：根據總體ipo圖，對頂層模塊進行重復逐層分解，而得到的 關于組成頂層模塊的所有功能模塊的層次結構關系圖。低層主要模塊詳細的ipo圖：由于hipo圖僅僅表示了一個系統(tǒng)功能模 塊的層次分解關系，還沒有充分說明各模塊間的調用關系和模塊間的數據流及信 息流的

24、傳遞關系。因此，對某些輸送低層上的重要工作模塊， 還必須根據數據字 典和hipo圖，繪制其詳細的ipo圖，用來描述模塊的輸入、處理和輸出細節(jié)， 以及與其他模塊間的調用和被調用關系。2.3 數據庫技術2.3.1 數據庫范式關系數據庫中的關系必須滿足一定的要求，即滿足不同的范式。目前關系 數據庫有六種范式：第一范式（1nf）、第二范式（2nf）、第三范式（3nf）、第 四范式（4nf）、第五范式（5nf）和第六范式（6nf）。滿足最低要求的范式是 第一范式（1nf）。在第一范式的基礎上進一步滿足更多要求的稱為第二范式（2nf）,其余范式以次類推。一般說來，數據庫只需滿足第三范式（3nf）就行 了。

25、第一范式（1nf）。所謂第一范式（1nf）是指數據庫表的每一列都是不可 分割的基本數據項，同一列中不能有多個值,即實體中的某個屬性不能有多個值 或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體， 新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一范式 （1nf）中表的每一行只包含一個實例的信息。簡而言之，第一范式就是無重復 的列。第二范式（2nf）。第二范式（2nf）是在第一范式（1nf）的基礎上建立 起來的，即滿足第二范式（2nf）必須先滿足第一范式（1nf）。第二范式（2nf） 要求數據庫表中的每個實例或行必須可以被唯一地區(qū)分。為實現區(qū)分通常需要為 表加上

26、一個列，以存儲各個實例的唯一標識。第二范式（2nf）要求實體的屬性 完全依賴于主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬 性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的 實體，新實體與原實體之間是一對多的關系。 為實現區(qū)分通常需要為表加上一個 列，以存儲各個實例的唯一標識。簡而言之，第二范式就是屬性完全依賴于主鍵。第三范式（3nf）。滿足第三范式（3nf）必須先滿足第二范式（2nf）。簡 而言之，第三范式（3nf）要求一個數據庫表中不包含已在其它表中已包含的非 主關鍵字信息。簡而言之，第三范式就是屬性不依賴于其它非主屬性。2.3.2 數據建模因為數據模型

27、的內容是問題域和解域所共享的知識模型，所以可以用問題域的語言來描述它，也可以用解域的語言來描述它，還可以用介于二者之間的語 言來描述，故產生了以下三種常用的數據模型：1）概念數據模型20它反映了人們對現實世界的認知與理解，是從現實世 界到人類大腦的映射。故它以問題域的語言解釋數據模型，由一系列應 用領域的概念組成。2）物理數據模型。它是以解域的語言解釋數據模型，是面向計算機物理表 示的模型，描述了數據在儲存介質上的組織結構，它不但與具體的dbms 有關，而且還與操作系統(tǒng)和硬件有關。每一種邏輯數據模型在實現時都 有起對應的物理數據模型。3）邏輯數據模型。這是用戶從數據庫所看到的模型，是具體的 d

28、bms所支 持的數據模型，如網狀數據模型 （network data model）、層次數據模型 （hierarchical data model）等等。此模型既要面向用戶， 又要面向系統(tǒng)，主 要用于數據庫管理系統(tǒng)（dbms）的實現。第三章需求分析軟件需求過程是整個軟件開發(fā)初始階段，對軟件的品質具有決定性的作用。 軟件需求工程研究如何理解和說明用戶對所開發(fā)軟件的要求和期望。需求就是以一種清晰、簡明、一致且無二義性的方式對一個待開發(fā)系統(tǒng)中的 各個方面有意義的陳述的集合4。需求必須是完整的，足以使設計師和工程師來 開發(fā)一個使客戶滿意的軟件制品。ieee軟件工程標準詞匯表（1997年）中定義需求為5

29、:（1） 用戶解決問題或達到目標所需的條件或能力（capability）;（2） 系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力；（3） 一種反映上面（l）或所描述的條件或能力的文檔說明。軟件需求包括三個不同的層次：業(yè)務需求、用戶需求和功能需求（也包括非 功能需求）6o3.1 業(yè)務需求業(yè)務需求（business requirement是客戶對軟件制品目標的高層次要求。3.1.1. 業(yè)務描述描述系統(tǒng)當前的主要業(yè)務問題，進一步闡述通過計算機軟件要達到哪些目 標，解決哪些主要問題等。示例：（一）能夠實現商品展小、商品檢索、商品選擇、網上訂貨、網上支付和 商品發(fā)貨等功能，對

30、網上購物的全過程進行管理（二）實現對網上購物過程中產生的所有業(yè)務數據的管理，如訂貨單、支 付記錄、發(fā)貨信息的管理與維護（三）具有配套的系統(tǒng)后臺管理維護功能，能夠對商品信息、用戶信息、 系統(tǒng)日志等信息進行管理與維護，并能夠進行對應的權限管理（四）響應速度合理，安全性較高（五）系統(tǒng)運行穩(wěn)定，并且應易于維護3.1.2. 主要業(yè)務流程圖（一）商品展示業(yè)務流程圖圖3-1商品展示業(yè)務流程圖（二）網上訂貨業(yè)務流程圖創(chuàng)建訂單通知賣家發(fā)貨退款 退貨處理 一申請退款圖3-2網上訂貨業(yè)務流程圖（三）貨款支付業(yè)務流程圖在購物車中選擇要進行結算的商品創(chuàng)建訂單否圖3-3貨款支付業(yè)務流程圖（四）發(fā)貨業(yè)務流程圖開始查看買家已

31、付款代發(fā)貨訂單進行發(fā)貨圖3-4商品發(fā)貨業(yè)務流程圖（五）退貨處理業(yè)務流程圖發(fā)起退貨申請賣家檢查申請圖3-5退貨處理業(yè)務流程圖3.2功能需求功能(function)是刻畫系統(tǒng)行為、特別是系統(tǒng)與環(huán)境關系的重要概念。用戶需 求(user requirement)述了待開發(fā)的軟件必須完成的任務。功能需求 (functional requirement義了必須實現的軟件功能，使得用戶通過這些功能完成他們的任 務，從而滿足業(yè)務需要。3.2.1角色分析從系統(tǒng)的角度分析系統(tǒng)的參與者，并給出每一個參與者的描述。以下從網上購物系統(tǒng)的實際需求分析，系統(tǒng)涉及到以下角色：角色職責或功能客戶(買家)系統(tǒng)主要參與者，進行商品

32、選購、商品退貨、貨款支付等賣家系統(tǒng)主要參與者，進行商品發(fā)貨、訂單管理、商品管理、統(tǒng)計查詢等系統(tǒng)管理員管理和維護整個系統(tǒng)的用戶組織結構，負責對用戶、角色、用戶級別的增、刪、改、查等管理。3.2.2業(yè)務功能從系統(tǒng)的使用者的角度使用數據流圖描述系統(tǒng)的功能，并給出數據字典描 述。在結構分析方法中，通常采用數據流圖(ddf)和數據字典(dd)工具。其中， 數據流圖是描述數據處理過程的工具。 數據流圖從數據傳遞和加工的角度， 以圖 形的方式刻畫系統(tǒng)邏輯模型及信息從輸入到輸出的移動變換過程。它是一種非常好的工具，一般把功能級數據流圖細化后得到的數據流圖很復雜，可以采用數據流圖分層表示，用劃分圖的方法把一個主

33、要功能都細化成為一張數據流分圖。畫數據流圖的基本步驟概括的說，就是自外向里、自頂鄉(xiāng)下、逐層細化、完善求精。以下從業(yè)務功能的角度出發(fā)，給出了系統(tǒng)的頂層數據流圖，如下圖所示：從頂層數據流圖中可以看出，系統(tǒng)的參與者主要分為三類，買家、賣家和管 理員。其中買家主要通過網上購物系統(tǒng)來瀏覽和購買商品；同時賣家將通過網上購物系統(tǒng)來對網上商城的商品進行維護， 對買家購買商品的訂單進行發(fā)貨， 從而 形成了整個購物的過程；除此之外，系統(tǒng)管理員在整個過程中參與系統(tǒng)的維護操 作，主要維護系統(tǒng)中的用戶信息、系統(tǒng)角色信息、用戶級別信息，另外對系統(tǒng)日 志進行查詢與監(jiān)控。表3-1源點“買家”詞條描述源點名稱：買家別名：購物者

34、簡述：對商品進行采購的用戶云南大學碩士研究生論文xx系統(tǒng)的分析與設計簡述：對系統(tǒng)進行維護的用戶為了進一步細化各加工步驟說明，下面給出了系統(tǒng)的一級數據流圖，并對數 據流的加工進行了進一步描述。圖3-7 一層數據流圖表3-4加工“商品選購”詞條描述加工名：商品選購加工編號：1簡要描述：買家對商品進行選購輸入數據流：商品類別、搜索條件輸出數據流：所選商品信息、擬創(chuàng)建訂單的商品清單加工邏輯：對商品進行選購并加入購物車或形成訂單加工名：貨款支付加工編號：2簡要描述：買家對商品進行付款輸入數據流：訂單詳細信息輸出數據流：買家信息加工邏輯：對訂單所包含商品進行結算并將買家信息交由商品發(fā)貨表3-6工“訂單管理

35、”詞條描述加工名：訂單管理加工編號：3簡要描述：買家選購商品形成訂單記錄輸入數據流：擬創(chuàng)建訂單的商品清單輸出數據流：訂單詳細信息加工邏輯：對商品信息進行處理形成訂單信息表3-7加工“發(fā)貨信息管理”詞條描述加工名：發(fā)貨信息管理加工編號：4簡要描述：買家對自己的收貨地址進行管理輸出數據流：已有發(fā)貨地址加工邏輯：對用戶的地址進行統(tǒng)一維護管理表3-8加工“退貨處理”詞條描述加工名：退貨處理加工編號：5簡要描述：買家或賣家對商品進行退貨和退貨審核的處理輸出數據流：退貨結果、退貨申請集合加工邏輯：根據退貨申請集合進行審核并進行退貨操作表3-9加工“商品管理”詞條描述云南大學碩士研究生論文xx系統(tǒng)的分析與設

36、計加工名：商品管理加工編號：6簡要描述：賣家對商品進行管理和維護輸入數據流：維護商品信息輸出數據流：無加工邏輯：對商品信息進行相應的維護表3-10加工“統(tǒng)計查詢”詞條描述加工名：統(tǒng)計查詢加工編號：7簡要描述：賣家對綜合信息進行統(tǒng)計查詢輸入數據流：統(tǒng)計條件輸出數據流：統(tǒng)計結果加工邏輯：對商城綜合信息進行統(tǒng)計并生成相應的結果表3-11加工“商品發(fā)貨”詞條描述加工名：商品發(fā)貨加工編號：8簡要描述：賣家進行發(fā)貨輸入數據流：買家信息輸出數據流：發(fā)貨信息加工邏輯：針對買家信息進行發(fā)貨操作，形成發(fā)貨信息通知買家表3-12加工“用戶管理”詞條描述加工名：用戶管理加工編號：9簡要描述：系統(tǒng)管理員對系統(tǒng)用戶進行維

37、護輸入數據流：用戶維護信息輸出數據流：用戶信息集合加工邏輯：對用戶信息進行相應的維護加工名：日志管理加工編號：10簡要描述：系統(tǒng)管理員對系統(tǒng)日志進行查詢輸入數據流：查詢條件輸出數據流：日志集合信息加工邏輯：對符合條件的日志信息進行提取表3-14加工”系統(tǒng)角色管理”詞條描述加工名：系統(tǒng)角色管理加工編號：11簡要描述：系統(tǒng)管理員對用戶的系統(tǒng)角色進行管理維護輸入數據流：角色維護信息輸出數據流：角色信息集合加工邏輯：對系統(tǒng)用戶的角色信息進行維護操作表3-15加工“用戶級別管理”詞條描述加工名：用戶級別管理加工編號：12簡要描述：系統(tǒng)管理員對用戶的級別進行管理輸入數據流：級別維護信息輸出數據流：界別信息

38、集合加工邏輯：對系統(tǒng)用戶的級別信息進行維護操作商品選購商品選購模塊加工和終點描述：表3-14終點“訂單管理”詞條描述終點名稱：訂單管理簡述：對訂單進行管理的接口數據流：擬創(chuàng)建訂單商品清單表3-15加工”商品信息獲取”詞條描述加工名：商品信息獲取加工編號：1.1簡要描述：獲取用戶所選商品類別或者所搜索關鍵字相關的商品信息集合輸入數據流：商品類別、搜索條件輸出數據流：購買商品清單、所選商品信息加工邏輯：從商品信息記錄中，獲取用戶所選商品類別的商品信息集合表3-16加工“購物車管理”詞條描述加工名：購物車管理加工編號：1.2簡要描述：買家所買商品記錄放入購物車或移出購物車輸入數據流：購

39、買商品清單輸出數據流：擬創(chuàng)建訂單商品清單加工邏輯：將買家所選商品id以及購買數量記錄到購物車記錄中根據數據流圖我們可以看出，該功能由買家開始，結束于訂單管理，其中買家為操作實體，而訂單管理為本模塊外的另一數據加工過程。 商品選購過程即是 買家針對所選中的商品進行采購，并將數據提交由訂單管理模塊處理的過程。在該模塊中，輸入數據有“搜索條件”、“商品類別”，輸出數據有“購買商 品清單”、“擬創(chuàng)建訂單商品清單”。同時該模塊還涉及“商品信息記錄”和“購物車記錄”兩個數據存儲文件。相應的數據字典描述將在數據需求中詳細展開所選商出精息7 搜索條件所選商品信息l 1. 1商乩檢索l ；2杳行商乩詳細信0)商

40、品信息把錄購買商品清單a購物乍管理v圖3-8商品信息獲取數據流圖根據數據流圖我們可以看出，商品信息獲取由買家開始，結束于購物車管理， 其中買家為操作實體，而購物車為本模塊外的另一數據加工過程。 該數據流圖為 圖3-7的下層數據流圖。表3-17加工“商品檢索”詞條描述加工名：商品檢索加工編號：1.1.1輸入數據流：搜索條件輸出數據流：購買商品清單加工邏輯：根據買家輸入的關鍵字與商品信息記錄中搜索相關商品信息表3-18加工“查看商品詳細信息”詞條描述加工名：查看商品詳細信息加工編號：1.1.2簡要描述：買家根據商品類別查看商品詳情的過程輸出數據流：購買商品清單加工邏輯：根據買家選擇的商品類別提取相

41、應的商品信息商品信息獲取i移除商品清單圖3-9購物車管理數據流圖根據數據流圖我們可以看出，購物車管理由商品信息獲取開始，結束于訂單 管理。該數據流圖為圖3-7的下層數據流圖。表3-19加工“商品加入購物車”詞條描述加工名：商品加入購物車加工編號：1.2.1簡要描述：買家所買商品記錄放入購物車輸入數據流：購買商品清單輸出數據流：商品數量加工邏輯：將買家所選商品記錄下來并加上購買數量表3-20加工“商品從購物車移除”詞條描述加工名：商品從購物車移除加工編號：1.2.2簡要描述：買家所買商品記錄移出購物車輸入數據流：移除商品清單輸出數據流：無加工邏輯：將買家不想購買的商品從購物車移除表3-21加工“

42、購買數量設置”詞條描述加工名：購買數量設置加工編號：1.2.3簡要描述：買家所買商品記錄放入購物車并設置購買數量輸入數據流：商品數量輸出數據流：擬創(chuàng)建訂單商品清單加工邏輯：將買家所選商品id以及購買數量記錄到購物車記錄中并創(chuàng)建商品訂單以下至ij 2小節(jié)請參照小節(jié), 貨款支付 訂單管理 發(fā)貨信息管理 退貨處理 商品管理 統(tǒng)計查詢 商品發(fā)貨 用戶管理0 日志管理1 系統(tǒng)角色管理2 用戶級別管理3.3數據需

43、求此處應根據3.2.2小節(jié)的用例圖，相對應的在本小節(jié)給出ipo圖，對功能數 據進行分析輸入商品基本信息a用戶購買信息a圖 3-15處理1 .商品選購2 .貨款支付3 .訂單管理4 .發(fā)貨信息管理5 .退貨處理6 .商品管理7 .統(tǒng)計查詢8 .商品發(fā)貨9 .用戶管理10 .日志管理11 .系統(tǒng)角色管理12 .用戶級別管理輸出交易訂單交易記錄網上購物系統(tǒng)總體ipo圖3.3.1 商品選購圖3-16商品選購ipo圖該功能主要負責實現買家通過直接按商品類別瀏覽商品或者輸入搜索條件 瀏覽商品這兩種手段進行商品選購的業(yè)務流程，輸入數據為商品類別和搜索條 件，輸出數據為購買商品清單和擬創(chuàng)建訂單商品清單。輸入數

44、據：1 .商品類別。2 .搜索條件。輸出數據：1 .購買商品清單。2 .擬創(chuàng)建訂單商品清單。商品選購模塊數據字典描述如下表所示：表3-22數據流“商品類別”詞條描述數據流名稱：商品類別別名：無簡述：買家查看商品信息時選擇的商品類別來源：買家去向：加工“商品查看”數據流量：1000份/每分組成：商品類別id+商品類別名稱+商品父類別id表3-23數據流“搜索條件”詞條描述數據流名稱：搜索條件別名：無簡述：買家查看商品信息時輸入的關鍵字信息來源：買家去向：加工“商品搜索”數據流量：1000份/每分組成：關鍵字表3-24數據文件“商品信息記錄”詞條描述數據文件名：商品信息記錄別名：無簡述：系統(tǒng)中所有

45、商品的信息數據文件組成：商品id+商品名稱+單價+庫存量+描述信息+商品照片+商品類別+商品狀態(tài)存儲方式：索引文件，以商品id為關鍵字存取頻率：異常頻繁查詢要求：要求能立即查詢表3-25數據流“購買商品清單”詞條描述數據流名稱：購買商品清單別名：無簡述：確定購買某商品時輸入的商品數量等信息來源：加工“商品查看”或加工“商品搜索”去向：加工“商品購買”數據流量：1000份/每分組成：商品id+購買數量表3-26數據文件“購物車記錄”詞條描述數據文件名：購物車記錄別名：無簡述：系統(tǒng)中各位買家購物車記錄的信息數據文件組成：購物車記錄id+購物車所有者id+商品id+購買數量+創(chuàng)建日期+冏品總額存儲方

46、式：索引文件，以購物車記錄id為關鍵字存取頻率：異常頻繁查詢要求：要求能立即查詢表3-27數據流“擬創(chuàng)建訂單商品清單”詞條描述數據流名稱：擬創(chuàng)建訂單商品清單別名：無簡述：買家擬創(chuàng)建訂單時所有的商品信息列表來源：加工“商品購買”去向：接口 “訂單管理”數據流量：1000份/每分組成：商品id+購買數量+創(chuàng)建日期表3-28數據項“商品類別id”詞條描述數據項名稱：商品類別id另名：goodtypeld簡述：商品類別信息唯一標識類型：guid 長度：無取值范圍及含義：隨機值，作唯一標識使用表3-29數據項“商品類別名稱”詞條描述數據項名稱：商品類別名稱別名:goodtypename簡述：商品類別的名

47、稱類型：字符串長度：20取值范圍及含義：無表3-30數據項“商品父類別id”詞條描述數據項名稱：商品父類別id別名:goodparenttypeld簡述：商品類別的父類別信息唯一標識類型：guid取值范圍及含義：隨機值，作唯一標識使用表3-31數據項“關鍵字”詞條描述數據項名稱：關鍵字別名：keywords簡述：搜索商品時所輸入的關鍵字信息類型：字符串長度：15取值范圍及含義：無表3-32數據項“商品id”詞條描述數據項名稱：商品id別名：goodid簡述：商品信息唯一標識類型：guid長度：無取值范圍及含義：隨機值，作唯一標識使用表3-33數據項“商品名稱”詞條描述數據項名稱：商品名稱另名：

48、goodname簡述：商品的名稱類型：字符串長度：150取值范圍及含義：無表3-34數據項“單價”詞條描述數據項名稱：單價別名:price簡述：商品的價格信息類型：浮點數氏度：無取值范圍及含義：“0”代表免費商品“0-1”代表附加商品“0-無窮”代表正常商品表3-35數據項“庫存量”詞條描述數據項名稱：庫存量別名:totalcount簡述：商品的庫存數目類型：整型長度：無取值范圍及含義：“0”代表該商品缺貨“0-10”代表該商品貨源緊張“0-無窮”代表正常商品表3-36數據項“描述信息”詞條描述數據項名稱：描述信息別名：decriptinfo簡述：商品的簡單描述信息類型：字符串長度：255取值

49、范圍及含義：無表3-37數據項“商品照片”詞條描述數據項名稱：商品照片別名：goodpic簡述：商品的照片信息類型：binary長度：無取值范圍及含義：無表3-38數據項“商品類別”詞條描述數據項名稱：商品類別別名:goodtypename簡述：商品的類別名稱長度：50取值范圍及含義：無表3-39數據項“商品狀態(tài)”詞條描述數據項名稱：商品狀態(tài)另名：goodtype簡述：商品的狀態(tài)描述信息類型：字符串長度：10取值范圍及含義：“缺貨”代表該商品暫時缺貨、“下架”代表該商品已下架不允 許購買、“熱賣”代表該商品短時間內被購買的次數較多、“正?！贝碓撋唐窢?態(tài)正常表3-40數據項“購買數量”詞條描

50、述數據項名稱：購買數量另名：buycount簡述：商品的購買數量多少類型：整型取值范圍及含義：無表3-41數據項“購物車記錄id ”詞條描述數據項名稱：購物車記錄id別名：cartid簡述：購物車記錄唯一標識類型：guid長度：無取值范圍及含義：隨機值，作唯一標識使用表3-42數據項“購物車所有者id”詞條描述數據項名稱：購物車所有者id云南大學碩士研究生論文xx系統(tǒng)的分析與設計別名：ownerld簡述：該購物車記錄所有者唯一標識類型：guid長度：無取值范圍及含義：隨機值，作唯一標識使用表3-43數據項“創(chuàng)建日期”詞條描述數據項名稱：創(chuàng)建日期別名：createdate簡述：創(chuàng)建的當前時間類型

51、：日期長度：無取值范圍及含義：無表3-44數據項“商品總額”詞條描述數據項名稱：商品總額別名:totalprice簡述：商品的總體價格描述長度：無取值范圍及含義：無以下3.3.2到3.3.12小節(jié)請參照3.3.1與3.3.2小節(jié)，給予補充說明3.3.2 貨款支付3.3.3 訂單管理3.3.5 退貨處理3.3.6 商品管理3.3.7 統(tǒng)計查詢3.3.8 商品發(fā)貨3.3.9 用戶管理3.3.10 日志管理3.3.11 系統(tǒng)角色管理3.3.12 用戶級別管理3.4非功能需求非功能需求口包括產品必須遵從的標準、規(guī)范和合約；外部界面的具體細節(jié) 和性能要求；設計或實現的約束條件及質量屬性。3.4.1 環(huán)境

52、需求表3.1服務器端環(huán)境系統(tǒng)所使用數據庫microsoft sql server 2008 sp1操作系統(tǒng)windows 2008 r2wet務器iis 7.5數據庫sql server 2008客戶端:表3.2客戶端環(huán)境操作系統(tǒng)windows xp或具以上版本操作系統(tǒng)瀏覽器ie 6.0 以及其以上版本（ie7.0、ie8.0 ）分辨率最佳效果為1024 x 768像素3.4.2 性能需求主要闡述系統(tǒng)運行相對于性能的相關需求，以下為范本 1 .可維護性維護方法：系統(tǒng)能真正做到使自身在數據損壞、丟失等情況下將備份數據倒 回，實現數據的恢復。提供對系統(tǒng)自身的集中操作維護的功能。2 .易操作性界面設

53、計：系統(tǒng)應提供美觀實用，方便和直觀的圖形用戶管理界面，充分考 慮員工的習慣，簡單易學，操作方便，所有菜單驅動的處理和各種快捷鍵，一鍵 功能以確保多數達到。3 .可擴展性功能擴展：系統(tǒng)從系統(tǒng)結構、功能設計、管理對象等各方面的功能擴展來考 慮，以滿足用戶今后系統(tǒng)擴充和擴大使用范圍的要求。軟硬件升級：系統(tǒng)應采取的硬件和軟件平臺，軟件和硬件的負載平衡機制的 可擴展性充分考慮。系統(tǒng)要具有靈活的擴展能力，來適應關鍵的軟件和硬件的開 發(fā)及管理能力的上升。4 .開放性系統(tǒng)的數據格式應符合國家相關標準及行業(yè)標準，以此確保應用程序具有良 好的互操作性和移植的可能。5 .4.3安全需求主要闡述有關系統(tǒng)運行的安全性保障的相關需求，以下為范本 1 .容錯性當用戶輸入或誤操作導致非法數據產生時