碩士論文寫作范本結構化方法(V)

云南大學碩士研究生論文 XX系統(tǒng)的分析與設計分類號TP31密級公開UDC編號碩士研究生學位論文題目XX系統(tǒng)的分析與設計學院（所、中心）軟件學院專業(yè)名稱軟件工程研究生姓名學號導師姓名職稱年月獨創(chuàng)性聲明本人聲明所呈交的論文是我個人在導師指導下進行的研究工作及取得的研究成果。除了文中特別加以標注和致謝的地方外，論文中不包含其他人或集體已經發(fā)表或撰寫過的研究成果，對本文的研究做出貢獻的集體和個人均已在論文中作了明確的說明并表示了謝意。 研究生簽名：日期：論文使用和授權說明本人完全了解云南大學有關保留、使用學位論文的規(guī)定，即：學校有權保留并向國家有關部門或機構送交學位論文和論文電子版；允許論文被查閱或借閱；學?？梢怨颊撐牡娜炕虿糠謨热?，可以采用影印、縮印或其他復制手段保存論文。（保密的論文在解密后應遵循此規(guī)定）研究生簽名：導師簽名：日期：…………………本人及導師同意將學位論文提交至清華大學“中國學術期刊（光盤版）電子雜志社”進行電子和網絡出版，并編入CNKI系列數據庫，傳播本學位論文的全部或部分內容，同意按《中國優(yōu)秀博碩士學位論文全文數據庫出版章程》規(guī)定享受相關權益。研究生簽名：導師簽名：日期：

摘要<簡單的論文總體描述>論文首先介紹了XX系統(tǒng)的研究背景，對所需要解決的問題進行了概述，討論了項目的研究意義與重要性，闡述了系統(tǒng)開發(fā)方法和相關技術；論文提出了系統(tǒng)的設計目標，對系統(tǒng)進行了詳細的需求分析，包括業(yè)務需求分析、功能需求分析、數據需求分析和非功能需求分析，給出了系統(tǒng)的業(yè)務流程圖、數據流圖、功能數據分析圖（IPO圖），并進行了數據字典描述；在系統(tǒng)設計中，對系統(tǒng)進行了總體設計與模塊設計，給出了系統(tǒng)總功能結構圖(H圖)，包括XX等功能模塊，分別給出了具體模塊設計的功能結構圖（H圖）、IPO表、和處理流程圖，詳細闡述了設計內容，并使用實體關系E-R圖和數據庫表結構對數據庫進行了詳細設計；論文最后對研究的內容進行了總結，闡述了本人的主要工作，指出了論文存在的不足，并對進一步的工作進行了展望。關鍵詞：XXXX；XXXX；XXXX；

Abstract<此處插入英文摘要，就是中文摘要的正確翻譯，注意關鍵詞的翻譯要準確>Keywords:<英文關鍵詞，要與中文摘要對應，例如：XXXX；XXXX；XXXX；

目錄<此處插入論文目錄>

引言項目背景與問題概述項目背景<此處插入論文中所述項目的項目背景，旨在突出社會發(fā)展背景、項目的出發(fā)點等等。以下是范本請不要照搬！>隨著科學技術的進步和社會經濟的發(fā)展，信息化進程已經成為一種必然的趨勢。近年來，由于信息化在多個領域取得了巨大的成就，為國家的經濟建設和社會發(fā)展做出了不可估量的貢獻。因此，人們認識到，作為國家信息化和社會信息化的重要組成部分之一的商業(yè)信息化，已然成為了促進社會經濟發(fā)展的一個增長點，也是推動商業(yè)發(fā)展的重要手段。商業(yè)信息化已經被越來越多的企業(yè)和商家所關注。網上購物最早在美國出現，1995年美國網上商店亞馬遜開業(yè)（A），美國第一家安全網絡銀行（FirstSecurityB）實現網上支付。而我國的網上購物系統(tǒng)發(fā)展相對較晚，在1998年，中國的第一筆網上交易成功，1999年隨著8848等B2C網站的正式開通，中國開始進入購物網站的實際階段。從起步到現在，十多年來網上購物發(fā)展迅速,在1998年，國內最大的商務拍賣網站易趣開始運行。在1999年B2C網站當當投入運營，2000年卓越成立,到2003年B2B網站阿里巴巴投資成立了C2C網站淘寶。網上購物的商家越來越多，同時網上購物的消費者數量也在迅速的發(fā)展與增長。截止到2005年上半年，我國的上網人數達到1.03億，其中網上購物者達到2000萬人，網上支付的比例增長到近半數，網上購物成交額已經累計達100億元。在長達6年的網上購物市場發(fā)展過程中，網上購物者漸漸開始接受并習慣新的購物消費方式，隨著網民人數增加，網上購物者人數有進一步擴大的趨勢。世界電子商務的快速度發(fā)展，同時B2B、B2C、C2C等一系列的結構快速度發(fā)展，這些都需要網上商城來支持，少則自己開個商店，大則阿里巴巴等電子商務，這些都成就了商城系統(tǒng)的出現，正因為網上電子商務的安全性與穩(wěn)定性的要求高，所以對商城系統(tǒng)也需要有一個嚴格的考驗。不少商家、公司只制作一個或幾個產品介紹的頁面，要修改資料，需要對網頁重新修改，客戶卻又不能在線下定單，需要通過多種步驟才能與商家取得聯系，其弊端是顯見的，首先是低效率、數據的嚴重冗余，其次是維護困難。顯然由這些簡單鏈接的頁面構成的網站在數據的共享性、人機的交互性以及網站維護性上都是很現實的問題。開發(fā)一個基于web的動態(tài)網上購物系統(tǒng)，對發(fā)展電子商務無疑是十分迫切的。問題概述<此處插入論文的論點，旨在突出論文討論解決的問題。>在信息技術日新月異的今天，隨著新技術、新功能的演變，開發(fā)一個XXX系統(tǒng)有著多種技術手段來實現。如何根據具體需求采用合適的技術來實現，是很多軟件開發(fā)者正在考慮的問題。<展開敘述一些傳統(tǒng)技術手段存在的問題>此外，現有的電子商務系統(tǒng)普遍存在著…….問題，一直得不到解決。<展開敘述一些傳統(tǒng)網上購物系統(tǒng)普遍存在的問題>研究的意義和重要性研究的意義<此處插入論文的研究意義，應該和1.1.2小節(jié)的問題概述相呼應>研究的重要性<此處插入研究的重要性，應該和1.1.2小節(jié)的問題概述相呼應>研究的內容和主要工作研究的內容<此處插入研究的內容，也應該和1.1.2小節(jié)的問題概述相呼應，簡要說明論文中的系統(tǒng)采用了什么樣的技術手段，采用了什么樣的組織架構，做了些什么研究工作，解決了哪些問題>本人主要工作<此處插入作者本人在項目中所負責或者完成的具體工作，應與1.3.1的研究內容相對應，簡述作者本人所做的研究工作。此外，如果論文所述項目為集體合作，則應該簡略指出作者本人所負責的工作。以下為范本！> 在此項目中，本人做了如下工作：<此處插入所做工作>在項目開發(fā)中，本人主要負責系統(tǒng)需求分析、功能性分析、系統(tǒng)整體數據庫設計、主體框架設計搭建、WEB端程序開發(fā)，系統(tǒng)文檔撰寫、系統(tǒng)整體測試以及歷史數據導入等工作。論文結構<此處插入該論文的整體結構，簡述論文的整體形式結構，并簡述每一章的主旨。以下為范本，請勿照搬！>本文由五章內容組成，其中：第一章介紹了本文的研究背景，對所需要解決的問題進行了概述，討論了項目的研究意義與重要性，闡述了論文的主要內容以及本人的主要工作。第二章闡述的是本文所涉及到的開發(fā)方法及相關技術，包括：軟件工程開發(fā)模型、結構化建模技術、數據庫技術等。第三章是本文的核心內容之一，針對系統(tǒng)的業(yè)務需求、功能需求、數據需求和非功能需求等進行了詳細分析，給出了主要的業(yè)務流程圖和數據流圖，并利用數據字典進行了詳細的描述，同時利用IPO圖進行了功能數據分析。第四章是本文的重點，在進行了系統(tǒng)總體設計的基礎上，采用功能結構圖、IPO表、核心處理流程圖等對系統(tǒng)的子模塊進行了功能性詳細設計，同時通過實體E-R圖和數據庫表結構對數據庫進行了詳細設計。第五章總結了本文所做的工作，同時對進一步的工作進行了展望。

系統(tǒng)的開發(fā)方法及相關技術<此處插入系統(tǒng)開發(fā)方法的統(tǒng)一概述，旨在簡要的解釋系統(tǒng)開發(fā)的方法和涉及的相關技術。以下為范本，請勿照搬！>本XXX系統(tǒng)采用基于XXX架構，對應使用XXX技術來展現其表示層，分別對不同需求的用戶服務，旨在最大程度滿足不同用戶的需求。服務層采用XXX技術來提供統(tǒng)一接口，降低其與其他系統(tǒng)間的耦合度，提供安全數據通信，提高系統(tǒng)可擴展性、兼容性以及集成能力?！?lt;此處插入其他所采用的技術手段>。 此外，系統(tǒng)采用增量模型進行開發(fā)，以應對不斷變化的需求，大量降低項目風險，保證系統(tǒng)核心功能，較快的交付可使用的模塊。<以下幾個小節(jié)將根據以上統(tǒng)一概述，較為詳細的逐一展開進行敘述，每一項具體開發(fā)方法或者相關技術的綜述獨立成為一個小節(jié)，每個小節(jié)下面具體有多少子小節(jié)并無具體規(guī)定，只要能講述清楚明白即可，以下為范本，請勿照搬！>軟件工程開發(fā)模型傳統(tǒng)瀑布模型瀑布模型(也稱為線性順序模型)，由溫斯頓·羅伊斯在1970年提出，在20世紀80年代以前，瀑布模型一直都是唯一被廣泛采用的軟件開發(fā)模型。這個模型中，軟件生命周期中的制訂計劃，需求分析，軟件設計，程序編寫，軟件測試和運行維護依次由上至下順序展開，如同瀑布流水，逐級下落，最終得到軟件產品。理想化的瀑布模型是單邊逐一而下的，認為人在工作過程中不可能犯錯誤。實際的瀑布模型是帶有反饋逐一而下的，當后一階段發(fā)現前一階段的錯誤時，可以修正前一階段的錯誤繼續(xù)完成后一階段的任務。圖2.1瀑布模型[1]瀑布模型的優(yōu)點：促進軟件開發(fā)工程化，為項目提供了按階段劃分的檢查點降低軟件開發(fā)的復雜度，當前一階段完成后，只需去關注后續(xù)階段可以在增量模型中使用瀑布模型瀑布模型的缺點：缺乏靈活性不適應用戶需求的變化，項目的各個階段之間極少有反饋如果軟件需求不明確或者經常變更需求，最終可能導致開發(fā)出的軟件與用戶預期的軟件不符，往往會導致大量的返工，有時甚至會給開發(fā)人員帶來災難性的后果，而這一點又常常在項目生命期的后期才有所覺察。改進的螺旋模型螺旋模型由巴利·玻姆于1988年正式發(fā)表了軟件系統(tǒng)開發(fā)的“螺旋模型”，它是將瀑布模型與演化模型相結合，并且增加了兩者所忽略的風險分析，彌補了兩者的不足之處，該模型通常用來指導大型軟件項目的開發(fā)軟件項目的開發(fā)，。軟件風險是任何軟件開發(fā)項目中都普遍存在的實際問題，項目越大，軟件越復雜，承擔該項目所冒的風險也越大。軟件風險駕馭的目標主要是在造成危害之前及時對風險進行識別，分析，采取對策進而消除或者減少風險的損害。螺旋模型將開發(fā)劃分為制訂計劃，風險分析，實施工程，客戶評估四類活動。沿著螺旋線每旋轉一圈，表示開發(fā)出一個更完善的新的軟件版本，如果開發(fā)風險過大，開發(fā)機構和客戶無法接受，項目就有可能就此終止。多數情況下，會沿著螺旋線繼續(xù)下去，自內向外逐步延伸，最終得到滿意產品。螺旋模型開發(fā)的成敗很大程度上依賴于風險評估的成敗。沿著螺旋線旋轉，在笛卡爾坐標的四個象限上分別表達了四類活動：制定計劃：確定軟件目標，選定實施方案，弄清項目開發(fā)的限制條件。風險分析：分析所選方案，考慮如何識別和消除風險。實施工程：實施軟件開發(fā)。客戶評估：評價軟件功能和性能，提出修改建議。圖2.2螺旋模型[]螺旋模型的優(yōu)點：設計上的靈活性,可以在項目的各個階段進行變更。以小的分段來構建大型系統(tǒng),使成本計算變得簡單容易。客戶始終參與每個階段的開發(fā),保證了項目不偏離正確方向以及項目的可控性。隨著項目推進,客戶始終掌握項目的最新信，從而他或她能夠和管理層有效地交互?？蛻粽J可這種公司內部的開發(fā)方式帶來的良好的溝通和高質量的產品。螺旋模型的缺點：很難讓用戶確信這種演化方法的結果是可以控制的。建設周期長，而軟件技術發(fā)展比較快，所以經常出現軟件開發(fā)完畢后，和當前的技術水平有了較大的差距，無法滿足當前用戶需求。面向對象的噴泉模型在面向對象的方法中，提出了于瀑布模型相對應的噴泉模型，該模型的主要特點是認為軟件生命周期的各個階段是相互重疊和多次反復的，它是一種以用戶需求為動力，以對象為驅動的模型，主要用于描述面向對象的軟件開發(fā)過程。噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進行開發(fā)。其優(yōu)點是可以提高軟件項目開發(fā)效率，節(jié)省開發(fā)時間，適應于面向對象的軟件開發(fā)過程。由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。噴泉一詞本身就體現了迭代和無間隙的特性。圖2.3噴泉模型[1]噴泉模型的優(yōu)點：軟件項目開發(fā)效率高，節(jié)省開發(fā)時間，適應于面向對象的軟件開發(fā)過程。噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進行開發(fā)。噴泉模型的缺點：由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。形式化方法模型包含了一組活動，他們導致了計算機軟件的數學規(guī)約。形式化方法使得軟件工程師們能夠通過應用一個嚴格的數學符號體系來規(guī)約、開發(fā)、和驗證基于計算機的系統(tǒng)。在開發(fā)中使用形式化方法時，它們提供了一種機制，能夠消除使用其它軟件過程模型難以克服的很多問題。二義性、不完整性、不一致性能被更容易地發(fā)現和糾正，而不是通過專門的評審，是通過對應用的數學分析。形式化方法提供了可以產生無缺陷軟件的承諾。結構化設計方法結構化方法要素結構化設計方法是基于模塊化、自頂向下細化、結構化程序設計等程序設計技術基礎發(fā)展起來的。其基本思想是：將軟件設計成由相對獨立且具有單一功能的模塊組成的結構。結構化設計是數據模型和過程模型的結合。在設計過程中，它從整個程序的結構出發(fā)，利用模塊結構圖表述程序模塊之間的關系。結構化設計的步驟如下：①評審和細化數據流圖；②確定數據流圖的類型；③把數據流圖映射到軟件模塊結構，設計出模塊結構的上層；④基于數據流圖逐步分解高層模塊，設計中下層模塊；⑤對模塊結構進行優(yōu)化，得到更為合理的軟件結構；⑥描述模塊接口。結構化設計的目的主要是使程序的結構盡可能反映要解決的問題的結構。在軟件設計與開發(fā)中，結構化設計工作是以需求分析階段的成果之一的“數據流圖”為主要依據，進一步推導出軟件的“系統(tǒng)功能結構圖”。結構化方法中常用的設計圖業(yè)務流程圖業(yè)務流程圖是一種描述系統(tǒng)內各單位、人員之間業(yè)務關系、作業(yè)順序和管理信息流向的圖表，利用它可以幫助分析人員找出業(yè)務流程中的不合理流向，它是物理模型。業(yè)務流程圖主要是描述業(yè)務走向，以業(yè)務處理過程為中心，一般沒有數據的概念。業(yè)務流程圖的元素：流程：流程是獲取一種或多種輸人并且創(chuàng)造一種對客戶有價值的輸出的一系列活動的集合；決策：用來表示選擇流程流向的控制節(jié)點，表示對問題判斷或判定（審核/審批/評審）環(huán)節(jié)；開始/結束：表示一系列流程開始或結束的控制節(jié)點；文檔：以文字或圖示描述的內容；數據：數據是具有一定意義的數字、字母、符號和模擬量等的通稱；數據庫：所有的信息(數據事實等)的匯集的載體。數據流圖數據流圖(DFD)是一種圖形化技術，它描繪信息流和數據從輸入移動到輸出的過程中所經受的變換。在數據流圖中沒有任何具體的物理部件，它只是描繪數據在軟件中流動和被處理的邏輯過程。數據流圖是系統(tǒng)邏輯功能的圖形表示，即使不是專業(yè)的計算機技術人員也容易理解它。它是分析員與用戶之間極好的通信工具，也是今后進行軟件設計的很好的出發(fā)點。為了表達數據處理過程的數據加工情況，需要采用層次結構的數據流圖。按照系統(tǒng)的層次結構進行逐步分解，并以分層的數據流圖反映這種結構關系，能清楚地表達和容易理解整個系統(tǒng)在多層數據流圖中，頂層流圖僅包含一個加工，它代表被開發(fā)系統(tǒng)。它的輸入流是該系統(tǒng)的輸入數據，輸出流是系統(tǒng)所輸出數據底層流圖是指其加工不需再做分解的數據流圖，它處在最底層中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續(xù)細化，形成子圖。數據字典數據詞典與數據流圖配合，能清楚地表達數據處理的要求。數據字典以詞條描述的形式予以展現，對于在數據流圖中每一個被命名的圖形元素，均加以定義，其內容有：名字、別名或編號、分類、描述、定義、位置、其它等。HIPO圖HIPO圖是IBM公司于70年代中期在層次結構圖的基礎上推出的一種描述系統(tǒng)結構和模塊內部處理功能的工具（技術）。很適于在自頂向下設計軟件的過程中使用。一個完整的HIPO圖包含兩個部分：H圖（即層次圖）和IPO圖。層次圖用于表示一個系統(tǒng)自頂向下的功能模塊層次結構；IPO圖來描述每個模塊的輸入、輸出及其要執(zhí)行的過程，是對每個模塊進行詳細設計的工具，它能夠方便地描繪輸入數據、對數據的處理和輸出數據之間的關系。HIPO圖由三個基本圖表組成，進行模塊層次功能分解遵循以下步驟：總體IPO圖：它是數據流程圖的初步分層細化結果，根據數據流程圖，將最高層處理模塊分解為輸入、處理、輸出三個功能模塊。HIPO圖：根據總體IPO圖，對頂層模塊進行重復逐層分解，而得到的關于組成頂層模塊的所有功能模塊的層次結構關系圖。低層主要模塊詳細的IPO圖：由于HIPO圖僅僅表示了一個系統(tǒng)功能模塊的層次分解關系，還沒有充分說明各模塊間的調用關系和模塊間的數據流及信息流的傳遞關系。因此，對某些輸送低層上的重要工作模塊，還必須根據數據字典和HIPO圖，繪制其詳細的IPO圖，用來描述模塊的輸入、處理和輸出細節(jié)，以及與其他模塊間的調用和被調用關系。數據庫技術數據庫范式關系數據庫中的關系必須滿足一定的要求，即滿足不同的范式。目前關系數據庫有六種范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。滿足最低要求的范式是第一范式（1NF）。在第一范式的基礎上進一步滿足更多要求的稱為第二范式（2NF），其余范式以次類推。一般說來，數據庫只需滿足第三范式（3NF）就行了。第一范式（1NF）。所謂第一范式（1NF）是指數據庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一范式（1NF）中表的每一行只包含一個實例的信息。簡而言之，第一范式就是無重復的列。第二范式（2NF）。第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求數據庫表中的每個實例或行必須可以被唯一地區(qū)分。為實現區(qū)分通常需要為表加上一個列，以存儲各個實例的唯一標識。第二范式（2NF）要求實體的屬性完全依賴于主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區(qū)分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二范式就是屬性完全依賴于主鍵。第三范式（3NF）。滿足第三范式（3NF）必須先滿足第二范式（2NF）。簡而言之，第三范式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。簡而言之，第三范式就是屬性不依賴于其它非主屬性。數據建模因為數據模型的內容是問題域和解域所共享的知識模型，所以可以用問題域的語言來描述它，也可以用解域的語言來描述它，還可以用介于二者之間的語言來描述，故產生了以下三種常用的數據模型：概念數據模型[2]。它反映了人們對現實世界的認知與理解，是從現實世界到人類大腦的映射。故它以問題域的語言解釋數據模型，由一系列應用領域的概念組成。物理數據模型。它是以解域的語言解釋數據模型，是面向計算機物理表示的模型，描述了數據在儲存介質上的組織結構，它不但與具體的DBMS有關，而且還與操作系統(tǒng)和硬件有關。每一種邏輯數據模型在實現時都有起對應的物理數據模型。邏輯數據模型。這是用戶從數據庫所看到的模型，是具體的DBMS所支持的數據模型，如網狀數據模型(NetworkDataModel)、層次數據模型(HierarchicalDataModel)等等。此模型既要面向用戶，又要面向系統(tǒng)，主要用于數據庫管理系統(tǒng)（DBMS）的實現。

需求分析軟件需求過程是整個軟件開發(fā)初始階段，對軟件的品質具有決定性的作用。軟件需求工程研究如何理解和說明用戶對所開發(fā)軟件的要求和期望。需求就是以一種清晰、簡明、一致且無二義性的方式對一個待開發(fā)系統(tǒng)中的各個方面有意義的陳述的集合[4]。需求必須是完整的，足以使設計師和工程師來開發(fā)一個使客戶滿意的軟件制品。IEEE軟件工程標準詞匯表(1997年)中定義需求為[5]：用戶解決問題或達到目標所需的條件或能力(Capability)；系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力；一種反映上面(l)或(2)所描述的條件或能力的文檔說明。軟件需求包括三個不同的層次：業(yè)務需求、用戶需求和功能需求（也包括非功能需求）[6]。業(yè)務需求業(yè)務需求(businessrequirement)是客戶對軟件制品目標的高層次要求。業(yè)務描述<描述系統(tǒng)當前的主要業(yè)務問題，進一步闡述通過計算機軟件要達到哪些目標，解決哪些主要問題等。示例：>能夠實現商品展示、商品檢索、商品選擇、網上訂貨、網上支付和商品發(fā)貨等功能，對網上購物的全過程進行管理實現對網上購物過程中產生的所有業(yè)務數據的管理，如訂貨單、支付記錄、發(fā)貨信息的管理與維護具有配套的系統(tǒng)后臺管理維護功能，能夠對商品信息、用戶信息、系統(tǒng)日志等信息進行管理與維護，并能夠進行對應的權限管理響應速度合理，安全性較高系統(tǒng)運行穩(wěn)定，并且應易于維護主要業(yè)務流程圖<使用業(yè)務流程圖描述系統(tǒng)的主要業(yè)務流程等。示例：>（一）商品展示業(yè)務流程圖圖3-1商品展示業(yè)務流程圖（二）網上訂貨業(yè)務流程圖圖3-2網上訂貨業(yè)務流程圖（三）貨款支付業(yè)務流程圖圖3-3貨款支付業(yè)務流程圖（四）發(fā)貨業(yè)務流程圖圖3-4商品發(fā)貨業(yè)務流程圖（五）退貨處理業(yè)務流程圖圖3-5退貨處理業(yè)務流程圖功能需求功能(function)是刻畫系統(tǒng)行為、特別是系統(tǒng)與環(huán)境關系的重要概念。用戶需求(UserRequirement)描述了待開發(fā)的軟件必須完成的任務。功能需求(FunctionalRequirement)定義了必須實現的軟件功能，使得用戶通過這些功能完成他們的任務，從而滿足業(yè)務需要。角色分析<從系統(tǒng)的角度分析系統(tǒng)的參與者，并給出每一個參與者的描述。>以下從網上購物系統(tǒng)的實際需求分析，系統(tǒng)涉及到以下角色：角色職責或功能客戶(買家)系統(tǒng)主要參與者，進行商品選購、商品退貨、貨款支付等賣家系統(tǒng)主要參與者，進行商品發(fā)貨、訂單管理、商品管理、統(tǒng)計查詢等系統(tǒng)管理員管理和維護整個系統(tǒng)的用戶組織結構，負責對用戶、角色、用戶級別的增、刪、改、查等管理。業(yè)務功能<從系統(tǒng)的使用者的角度使用數據流圖描述系統(tǒng)的功能，并給出數據字典描述。>在結構分析方法中，通常采用數據流圖(DDF)和數據字典(DD)工具。其中，數據流圖是描述數據處理過程的工具。數據流圖從數據傳遞和加工的角度，以圖形的方式刻畫系統(tǒng)邏輯模型及信息從輸入到輸出的移動變換過程。它是一種非常好的工具，一般把功能級數據流圖細化后得到的數據流圖很復雜，可以采用數據流圖分層表示，用劃分圖的方法把一個主要功能都細化成為一張數據流分圖。畫數據流圖的基本步驟概括的說，就是自外向里、自頂鄉(xiāng)下、逐層細化、完善求精。以下從業(yè)務功能的角度出發(fā)，給出了系統(tǒng)的頂層數據流圖，如下圖所示：圖3-6頂層數據流圖從頂層數據流圖中可以看出，系統(tǒng)的參與者主要分為三類，買家、賣家和管理員。其中買家主要通過網上購物系統(tǒng)來瀏覽和購買商品；同時賣家將通過網上購物系統(tǒng)來對網上商城的商品進行維護，對買家購買商品的訂單進行發(fā)貨，從而形成了整個購物的過程；除此之外，系統(tǒng)管理員在整個過程中參與系統(tǒng)的維護操作，主要維護系統(tǒng)中的用戶信息、系統(tǒng)角色信息、用戶級別信息，另外對系統(tǒng)日志進行查詢與監(jiān)控。表3-1源點“買家”詞條描述源點名稱：買家別名：購物者簡述：對商品進行采購的用戶表3-2源點“賣家”詞條描述源點名稱：買家別名：商家簡述：出售商品的用戶表3-3源點“系統(tǒng)管理員”詞條描述源點名稱：系統(tǒng)管理員別名：管理者簡述：對系統(tǒng)進行維護的用戶為了進一步細化各加工步驟說明，下面給出了系統(tǒng)的一級數據流圖，并對數據流的加工進行了進一步描述。圖3-7一層數據流圖表3-4加工“商品選購”詞條描述加工名：商品選購加工編號：1簡要描述：買家對商品進行選購輸入數據流：商品類別、搜索條件輸出數據流：所選商品信息、擬創(chuàng)建訂單的商品清單加工邏輯：對商品進行選購并加入購物車或形成訂單表3-5“貨款支付”詞條描述加工名：貨款支付加工編號：2簡要描述：買家對商品進行付款輸入數據流：訂單詳細信息輸出數據流：買家信息加工邏輯：對訂單所包含商品進行結算并將買家信息交由商品發(fā)貨表3-6工“訂單管理”詞條描述加工名：訂單管理加工編號：3簡要描述：買家選購商品形成訂單記錄輸入數據流：擬創(chuàng)建訂單的商品清單輸出數據流：訂單詳細信息加工邏輯：對商品信息進行處理形成訂單信息表3-7加工“發(fā)貨信息管理”詞條描述加工名：發(fā)貨信息管理加工編號：4簡要描述：買家對自己的收貨地址進行管理輸入數據流：發(fā)貨地址輸出數據流：已有發(fā)貨地址加工邏輯：對用戶的地址進行統(tǒng)一維護管理表3-8加工“退貨處理”詞條描述加工名：退貨處理加工編號：5簡要描述：買家或賣家對商品進行退貨和退貨審核的處理輸入數據流：申請退貨訂單、審核信息輸出數據流：退貨結果、退貨申請集合加工邏輯：根據退貨申請集合進行審核并進行退貨操作表3-9加工“商品管理”詞條描述加工名：商品管理加工編號：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)用戶進行維護輸入數據流：用戶維護信息輸出數據流：用戶信息集合加工邏輯：對用戶信息進行相應的維護表3-13加工“日志管理”詞條描述加工名：日志管理加工編號：10簡要描述：系統(tǒng)管理員對系統(tǒng)日志進行查詢輸入數據流：查詢條件輸出數據流：日志集合信息加工邏輯：對符合條件的日志信息進行提取表3-14加工“系統(tǒng)角色管理”詞條描述加工名：系統(tǒng)角色管理加工編號：11簡要描述：系統(tǒng)管理員對用戶的系統(tǒng)角色進行管理維護輸入數據流：角色維護信息輸出數據流：角色信息集合加工邏輯：對系統(tǒng)用戶的角色信息進行維護操作表3-15加工“用戶級別管理”詞條描述加工名：用戶級別管理加工編號：12簡要描述：系統(tǒng)管理員對用戶的級別進行管理輸入數據流：級別維護信息輸出數據流：界別信息集合加工邏輯：對系統(tǒng)用戶的級別信息進行維護操作商品選購圖3-7商品選購數據流圖商品選購模塊加工和終點描述：表3-14終點“訂單管理”詞條描述終點名稱：訂單管理別名：無簡述：對訂單進行管理的接口數據流：擬創(chuàng)建訂單商品清單表3-15加工“商品信息獲取”詞條描述加工名：商品信息獲取加工編號：1.1簡要描述：獲取用戶所選商品類別或者所搜索關鍵字相關的商品信息集合輸入數據流：商品類別、搜索條件輸出數據流：購買商品清單、所選商品信息加工邏輯：從商品信息記錄中，獲取用戶所選商品類別的商品信息集合表3-16加工“購物車管理”詞條描述加工名：購物車管理加工編號：1.2簡要描述：買家所買商品記錄放入購物車或移出購物車輸入數據流：購買商品清單輸出數據流：擬創(chuàng)建訂單商品清單加工邏輯：將買家所選商品ID以及購買數量記錄到購物車記錄中根據數據流圖我們可以看出，該功能由買家開始，結束于訂單管理，其中買家為操作實體，而訂單管理為本模塊外的另一數據加工過程。商品選購過程即是買家針對所選中的商品進行采購，并將數據提交由訂單管理模塊處理的過程。在該模塊中，輸入數據有“搜索條件”、“商品類別”，輸出數據有“購買商品清單”、“擬創(chuàng)建訂單商品清單”。同時該模塊還涉及“商品信息記錄”和“購物車記錄”兩個數據存儲文件。相應的數據字典描述將在數據需求中詳細展開。圖3-8商品信息獲取數據流圖根據數據流圖我們可以看出，商品信息獲取由買家開始，結束于購物車管理，其中買家為操作實體，而購物車為本模塊外的另一數據加工過程。該數據流圖為圖3-7的下層數據流圖。表3-17加工“商品檢索”詞條描述加工名：商品檢索加工編號：1.1.1簡要描述：買家根據關鍵字檢索商品的過程輸入數據流：搜索條件輸出數據流：購買商品清單加工邏輯：根據買家輸入的關鍵字與商品信息記錄中搜索相關商品信息表3-18加工“查看商品詳細信息”詞條描述加工名：查看商品詳細信息加工編號：1.1.2簡要描述：買家根據商品類別查看商品詳情的過程輸入數據流：商品類別輸出數據流：購買商品清單加工邏輯：根據買家選擇的商品類別提取相應的商品信息圖3-9購物車管理數據流圖根據數據流圖我們可以看出，購物車管理由商品信息獲取開始，結束于訂單管理。該數據流圖為圖3-7的下層數據流圖。表3-19加工“商品加入購物車”詞條描述加工名：商品加入購物車加工編號：1.2.1簡要描述：買家所買商品記錄放入購物車輸入數據流：購買商品清單輸出數據流：商品數量加工邏輯：將買家所選商品記錄下來并加上購買數量表3-20加工“商品從購物車移除”詞條描述加工名：商品從購物車移除加工編號：1.2.2簡要描述：買家所買商品記錄移出購物車輸入數據流：移除商品清單輸出數據流：無加工邏輯：將買家不想購買的商品從購物車移除表3-21加工“購買數量設置”詞條描述加工名：購買數量設置加工編號：1.2.3簡要描述：買家所買商品記錄放入購物車并設置購買數量輸入數據流：商品數量輸出數據流：擬創(chuàng)建訂單商品清單加工邏輯：將買家所選商品ID以及購買數量記錄到購物車記錄中并創(chuàng)建商品訂單<以下到2小節(jié)請參照小節(jié)>貨款支付訂單管理發(fā)貨信息管理退貨處理商品管理統(tǒng)計查詢商品發(fā)貨用戶管理日志管理系統(tǒng)角色管理用戶級別管理數據需求<此處應根據3.2.2小節(jié)的數據流圖，相對應的在本小節(jié)給出IPO圖，對功能數據進行分析>圖3-15網上購物系統(tǒng)總體IPO圖商品選購圖3-16商品選購IPO圖該功能主要負責實現買家通過直接按商品類別瀏覽商品或者輸入搜索條件瀏覽商品這兩種手段進行商品選購的業(yè)務流程，輸入數據為商品類別和搜索條件，輸出數據為購買商品清單和擬創(chuàng)建訂單商品清單。輸入數據：商品類別。搜索條件。輸出數據：購買商品清單。擬創(chuàng)建訂單商品清單。商品選購模塊數據字典描述如下表所示：表3-22數據流“商品類別”詞條描述數據流名稱：商品類別別名：無簡述：買家查看商品信息時選擇的商品類別來源：買家去向：加工“商品查看”數據流量：1000份/每分組成：商品類別ID+商品類別名稱+商品父類別ID表3-23數據流“搜索條件”詞條描述數據流名稱：搜索條件別名：無簡述：買家查看商品信息時輸入的關鍵字信息來源：買家去向：加工“商品搜索”數據流量：1000份/每分組成：{關鍵字}表3-24數據文件“商品信息記錄”詞條描述數據文件名：商品信息記錄別名：無簡述：系統(tǒng)中所有商品的信息數據文件組成：商品ID+商品名稱+單價+庫存量+描述信息+商品照片+商品類別+商品狀態(tài)存儲方式：索引文件，以商品ID為關鍵字存取頻率：異常頻繁查詢要求：要求能立即查詢表3-25數據流“購買商品清單”詞條描述數據流名稱：購買商品清單別名：無簡述：確定購買某商品時輸入的商品數量等信息來源：加工“商品查看”或加工“商品搜索”去向：加工“商品購買”數據流量：1000份/每分組成：商品ID+購買數量表3-26數據文件“購物車記錄”詞條描述數據文件名：購物車記錄別名：無簡述：系統(tǒng)中各位買家購物車記錄的信息數據文件組成：購物車記錄ID+購物車所有者Id+商品Id+購買數量+創(chuàng)建日期+商品總額存儲方式：索引文件，以購物車記錄ID為關鍵字存取頻率：異常頻繁查詢要求：要求能立即查詢表3-27數據流“擬創(chuàng)建訂單商品清單”詞條描述數據流名稱：擬創(chuàng)建訂單商品清單別名：無簡述：買家擬創(chuàng)建訂單時所有的商品信息列表來源：加工“商品購買”去向：接口“訂單管理”數據流量：1000份/每分組成：{商品ID+購買數量}+創(chuàng)建日期表3-28數據項“商品類別ID”詞條描述數據項名稱：商品類別ID別名：GoodTypeId簡述：商品類別信息唯一標識類型：GUID長度：無取值范圍及含義：隨機值，作唯一標識使用表3-29數據項“商品類別名稱”詞條描述數據項名稱：商品類別名稱別名：GoodTypeName簡述：商品類別的名稱類型：字符串長度：20取值范圍及含義：無表3-30數據項“商品父類別ID”詞條描述數據項名稱：商品父類別ID別名：GoodParentTypeId簡述：商品類別的父類別信息唯一標識類型：GUID長度：無取值范圍及含義：隨機值，作唯一標識使用表3-31數據項“關鍵字”詞條描述數據項名稱：關鍵字別名：KeyWords簡述：搜索商品時所輸入的關鍵字信息類型：字符串長度：15取值范圍及含義：無表3-32數據項“商品ID”詞條描述數據項名稱：商品ID別名：GoodId簡述：商品信息唯一標識類型：GUID長度：無取值范圍及含義：隨機值，作唯一標識使用表3-33數據項“商品名稱”詞條描述數據項名稱：商品名稱別名：GoodName簡述：商品的名稱類型：字符串長度：150取值范圍及含義：無表3-34數據項“單價”詞條描述數據項名稱：單價別名：Price簡述：商品的價格信息類型：浮點數長度：無取值范圍及含義：“0”代表免費商品“0-1”代表附加商品“0-無窮”代表正常商品表3-35數據項“庫存量”詞條描述數據項名稱：庫存量別名：TotalCount簡述：商品的庫存數目類型：整型長度：無取值范圍及含義：“0”代表該商品缺貨“0-10”代表該商品貨源緊張“0-無窮”代表正常商品表3-36數據項“描述信息”詞條描述數據項名稱：描述信息別名：DecriptInfo簡述：商品的簡單描述信息類型：字符串長度：255取值范圍及含義：無表3-37數據項“商品照片”詞條描述數據項名稱：商品照片別名：GoodPic簡述：商品的照片信息類型：Binary長度：無取值范圍及含義：無表3-38數據項“商品類別”詞條描述數據項名稱：商品類別別名：GoodTypeName簡述：商品的類別名稱類型：字符串長度：50取值范圍及含義：無表3-39數據項“商品狀態(tài)”詞條描述數據項名稱：商品狀態(tài)別名：GoodType簡述：商品的狀態(tài)描述信息類型：字符串長度：10取值范圍及含義：“缺貨”代表該商品暫時缺貨、“下架”代表該商品已下架不允許購買、“熱賣”代表該商品短時間內被購買的次數較多、“正常”代表該商品狀態(tài)正常表3-40數據項“購買數量”詞條描述數據項名稱：購買數量別名：BuyCount簡述：商品的購買數量多少類型：整型長度：無取值范圍及含義：無表3-41數據項“購物車記錄ID”詞條描述數據項名稱：購物車記錄ID別名：CartId簡述：購物車記錄唯一標識類型：GUID長度：無取值范圍及含義：隨機值，作唯一標識使用表3-42數據項“購物車所有者Id”詞條描述數據項名稱：購物車所有者Id別名：OwnerId簡述：該購物車記錄所有者唯一標識類型：GUID長度：無取值范圍及含義：隨機值，作唯一標識使用表3-43數據項“創(chuàng)建日期”詞條描述數據項名稱：創(chuàng)建日期別名：CreateDate簡述：創(chuàng)建的當前時間類型：日期長度：無取值范圍及含義：無表3-44數據項“商品總額”詞條描述數據項名稱：商品總額別名：TotalPrice簡述：商品的總體價格描述類型：浮點型長度：無取值范圍及含義：無<以下3.3.2到3.3.12小節(jié)請參照3.3.1與3.3.2小節(jié)，給予補充說明>貨款支付訂單管理發(fā)貨信息管理退貨處理商品管理統(tǒng)計查詢商品發(fā)貨用戶管理日志管理系統(tǒng)角色管理用戶級別管理非功能需求非功能需求[7]包括產品必須遵從的標準、規(guī)范和合約；外部界面的具體細節(jié)和性能要求；設計或實現的約束條件及質量屬性。環(huán)境需求<包括硬件環(huán)境和軟件環(huán)境，以下為范本請根據實際情況加以修改>表3.1服務器端環(huán)境系統(tǒng)所使用數據庫MicrosoftSQLServer2008SP1操作系統(tǒng)Windows2008R2Web服務器IIS7.5數據庫SQLServer2008客戶端：表3.2客戶端環(huán)境操作系統(tǒng)WindowsXP或其以上版本操作系統(tǒng)瀏覽器IE6.0以及其以上版本（IE7.0、IE8.0）分辨率最佳效果為1024×768像素性能需求<主要闡述系統(tǒng)運行相對于性能的相關需求，以下為范本>可維護性維護方法：系統(tǒng)能真正做到使自身在數據損壞、丟失等情況下將備份數據倒回，實現數據的恢復。提供對系統(tǒng)自身的集中操作維護的功能。易操作性界面設計：系統(tǒng)應提供美觀實用，方便和直觀的圖形用戶管理界面，充分考慮員工的習慣，簡單易學，操作方便，所有菜單驅動的處理和各種快捷鍵，一鍵功能以確保多數達到?？蓴U展性功能擴展：系統(tǒng)從系統(tǒng)結構、功能設計、管理對象等各方面的功能擴展來考慮，以滿足用戶今后系統(tǒng)擴充和擴大使用范圍的要求。軟硬件升級：系統(tǒng)應采取的硬件和軟件平臺，軟件和硬件的負載平衡機制的可擴展性充分考慮。系統(tǒng)要具有靈活的擴展能力，來適應關鍵的軟件和硬件的開發(fā)及管理能力的上升。開放性系統(tǒng)的數據格式應符合國家相關標準及行業(yè)標準，以此確保應用程序具有良好的互操作性和移植的可能。安全需求<主要闡述有關系統(tǒng)運行的安全性保障的相關需求，以下為范本>容錯性當用戶輸入或誤操作導致非法數據產生時，系統(tǒng)應具有一定的容錯機制。在這種情況下，系統(tǒng)應給出友好的提示，提示用戶重新輸入或者進行自動的修復校正。系統(tǒng)的外在環(huán)境安全安全系統(tǒng)要以充分考慮網絡的高級別，多層次的安全性措施為前提，包括系統(tǒng)的備份，防火墻，用戶權限和其他措施，以確保數據安全和機密信息不被泄露；考慮到系統(tǒng)的硬件和軟件故障恢復等應急措施，以保障網絡的安全和處理安全性。形成相對獨立的安全機制，以防止來自系統(tǒng)外的未經授權的訪問。系統(tǒng)內部安全確保外部系統(tǒng)安全的同時，該系統(tǒng)還必須確保授權用戶的合法使用。系統(tǒng)運行安全從邏輯上講，該系統(tǒng)應具有抵抗非法入侵的能力；在物理方面，該系統(tǒng)應確保沒有潛在的單點故障，并提供資源的數據備份功能。系統(tǒng)支持定期自動和手動數據備份，能夠在數據損壞或數據丟失的情況下找回數據，實現一定程度的數據恢復。

系統(tǒng)設計4.1總體設計在結構化的系統(tǒng)設計方法中，系統(tǒng)功能設計可以采用HIPO圖、系統(tǒng)流程圖、形式語言等方法進行，本文采用HIPO圖方法對系統(tǒng)的總體功能和詳細功能進行設計。HIPO圖即是美國IBM公司于上個世紀70年代中期在層次結構圖的基礎上推出的一種描述系統(tǒng)結構和模塊內部處理功能的工具和。HIPO圖由層次結構圖(即H圖)和IPO圖兩部分構成,H圖描述了整個系統(tǒng)的設計結構以及各類模塊之間的關系,IPO圖描述了某個特定模塊內部的處理過程和輸入/輸出關系。因此，系統(tǒng)的總體功能將采用H圖進行描述，而功能模塊的具體功能設計則采用IPO圖進行描述。網上購物系統(tǒng)最主要的就是針對廣大用戶在互聯網上購物的需求和特點進行系統(tǒng)總體結構設計。而在購物過程中，主要是為了應對商品的選購，購物訂單的下達，貨款的支付，用戶信息的處理和查詢等操作，以便于整個購物系統(tǒng)的有序的進行和管理，規(guī)范化和統(tǒng)一化，對不同模塊進行分工管理，最后由系統(tǒng)統(tǒng)一實施。在系統(tǒng)總體功能設計階段采用HIPO圖的H圖對系統(tǒng)總體功能進行設計和描述，網上購物系統(tǒng)H圖見圖4-1所示。圖4-1網上購物系統(tǒng)的H圖如上圖所示，系統(tǒng)一共分為商品選購、貨款支付、訂單管理、發(fā)貨信息管理、退貨處理、商品管理、統(tǒng)計查詢、商品發(fā)貨、用戶管理、日志管理、系統(tǒng)角色管理和用戶級別管理共12個模塊。其中商品選購主要滿足買家通過系統(tǒng)購買商品的功能需求；貨款支付主要為了滿足買家購買商品時進行付款的功能需；訂單管理主要滿足買家對自己的訂單進行維護的功能需求；發(fā)貨信息管理主要為了滿足買家進行發(fā)貨信息維護的功能需求；退貨管理主要為了滿足買家對不滿意的商品進行退換貨的功能需求；商品發(fā)貨主要為了滿足賣家對買家購買商品進行發(fā)貨管理的功能需求；退貨審核主要為了滿足賣家對買家的退貨申請進行審核的功能需求；統(tǒng)計查詢主要為了滿足賣家對自己的業(yè)務數據進行統(tǒng)計的功能需求；商品管理功能主要為了滿足賣家維護自己所賣商品的功能需求；此外，用戶管理、用戶級別管理、系統(tǒng)角色管理和日志管理都主要為了滿足系統(tǒng)管理員對系統(tǒng)進行維護的功能需求。4.2系統(tǒng)功能模塊設計商品選購功能結構設計圖4-2商品選購模塊的H圖“商品選購”功能主要目的是為買家提供購買賣家提供的商品的功能；此外，該功能還負責將用戶選中的商品放入購物車，對購物車進行管理。因此，商品選購模塊主要涉及商品信息的查詢獲取以及購物車管理兩個子模塊。其中商品信息獲取模塊主要分為檢索商品和查看商品詳細信息兩個組成部分.購物車管理又分為將商品放入購物車和將商品從購物車移除和購買數量設置三個部分。功能設計.1商品信息獲取輸入數據設計商品類別：其定義參見表3-22。輸出數據設計商品信息集合：{商品ID+商品名稱+單價+庫存量+描述信息+商品照片+商品類別+商品狀態(tài)}IPO表表4-1商品信息獲取IPO表系統(tǒng)名稱：網上購物系統(tǒng)設計者：模塊名稱：商品信息獲取日期：2012年12月14日上層調用模塊：商品選購可調用模塊：商品檢索、查看商品詳細信息輸入處理輸出獲取規(guī)則商品信息集合 上述IPO表只是“商品信息獲取”的粗粒度分析，“商品信息獲取”還分為“商品檢索”和“查看商品詳細信息”兩個部分，下面將分別對這兩個部分進行詳細描述，并對核心流程給予說明。.1.1商品檢索輸入數據設計搜索條件：其定義參見表3-23。輸出數據設計商品信息集合：{商品ID+商品名稱+單價+庫存量+描述信息+商品照片+商品類別+商品狀態(tài)}IPO表表4-2商品檢索IPO表系統(tǒng)名稱：網上購物系統(tǒng)設計者：模塊名稱：商品檢索日期：2012年12月14日上層調用模塊：商品信息獲取可調用模塊：無輸入處理輸出商品類別搜索條件商品信息集合核心處理流程圖<使用核心處理流程圖描述上面IPO表中所述核心操作的處理流程。根據表4-2，“返回結果信息”這樣的步驟比較簡單，不需要進一步描述>在上述IPO表4-2中，對于“按類別獲取商品信息”以及“按條件獲取商品信息”的描述還不夠準確，將在下面具體予以說明，具體請參照圖4-3及圖4-4。圖4-3按類別獲取商品信息流程圖圖4-4按條件獲取商品信息流程圖.1.2查看商品詳細信息輸入數據設計商品ID：商品信息的唯一標識，類型為GUID。其定義參見表3-32。輸出數據設計商品信息：其定義參見表3-24。IPO表表4-3查看商品詳細信息IPO表系統(tǒng)名稱：網上購物系統(tǒng)設計者：模塊名稱：查看商品詳細信息日期：2012年12月14日上層調用模塊：商品信息獲取可調用模塊：無輸入處理輸出商品ID商品詳細信息核心處理流程圖<使用核心處理流程圖描述上面IPO表中所述核心操作的處理流程。根據表4-3，“返回該商品詳細信息”這樣的步驟比較簡單，不需要進一步描述> 在上述IPO表4-3中，對于“根據商品ID檢索商品詳細信息”的描述還不夠準確，將在下面的核心處理流程圖中進行說明，具體請參照圖4-5。圖4-5根據商品ID檢索商品詳細信息流程圖.2購物車管理輸入數據設計購買商品清單：其定義參見表3-25。刪除商品清單：其定義參見表3-25。輸出數據設計購物車管理的結果提示：“操作成功”，“操作失敗，請聯系管理員！”IPO表表4-4購物車管理IPO表系統(tǒng)名稱：網上購物系統(tǒng)設計者：模塊名稱：購物車管理日期：2012年12月14日上層調用模塊：商品選購可調用模塊：商品加入購物、商品從購物車移除、購買數量設置輸入處理輸出購買商品清單購物車記錄存取結果或擬創(chuàng)建訂單商品清單 上述IPO表只是“購物車管理”的粗粒度分析，“購物車管理”還分為“商品加入購物車”、“商品從購物車移除”和“購買數量設置”三個部分，下面將分別對這三個部分進行詳細描述，并對核心流程給予說明。.2.1商品加入購物車輸入數據設計購買商品信息：其定義參見表3-25。輸出數據設計操作結果：“操作成功”、“操作失敗，請聯系管理員！”擬創(chuàng)建訂單商品清單：其定義參見表3-27。IPO表表4-5商品加入購物車IPO表系統(tǒng)名稱：網上購物系統(tǒng)設計者：模塊名稱：商品加入購物車日期：2012年12月14日上層調用模塊：購物車管理可調用模塊：無輸入處理輸出購買商品清單操作結果擬創(chuàng)建訂單商品清單 核心處理流程圖<使用核心處理流程圖描述上面IPO表中所述核心操作的處理流程。根據表4-5，“商品加入購物車”必須要進一步描述，請注意，因為此文是范本，因此這里沒有對“生成擬創(chuàng)建訂單商品清單”這一步驟進行細化，但是在正式論文中，該步驟也必須細化出來>在上述IPO表4-5中，對于“商品加入購物車”的描述還不夠準確，將在下面的核心處理流程圖中進行說明，具體請參照圖4-6。圖4-6商品加入購物車流程圖.2.2商品從購物車移除輸入數據設計要移除商品信息：其定義參見表3-25。輸出數據設計操作結果：“操作成功”、“操作失敗，請聯系管理員！”擬創(chuàng)建訂單商品清單：其定義參見表3-27。IPO表表4-6商品從購物車移除IPO表系統(tǒng)名稱：網上購物系統(tǒng)設計者：模塊名稱：商品從購物車移除日期：2012年12月14日上層調用模塊：購物車管理可調用模塊：無輸入處理輸出要移除商品信息操作結果擬創(chuàng)建訂單物品清單核心處理流程圖<使用核心處理流程圖描述上面IPO表中所述核心操作的處理流程。根據表4-6，“商品加入購物車”必須要進一步描述，請注意，因為此文是范本，因此這里沒有對“新建擬創(chuàng)建訂單商品清單”、“傳遞給訂單管理處理”這幾個步驟進行細化，但是在正式論文中，這幾個步驟也必須細化出來> 在上述IPO表4-6中，對于“根據要移除商品信息刪除購物車相關記錄”的描述還不夠準確，將在下面的核心處理流程圖中進行說明，具體請參照圖4-7。圖4-7根據要移除商品信息刪除購物車相關記錄流程圖.2.3購買數量設置輸入數據設計購買數量：其定義參見表3-40。輸出數據設計購買商品清單：其定義參見表3-25。IPO表表4-7購買數量設置IPO表系統(tǒng)名稱：網上購物系統(tǒng)設計者：模塊名稱：購買數量設置日期：2012年12月14日上層調用模塊：購物車管理可調用模塊：無輸入處理輸出購買數量購買商品清單核心處理流程圖<使用核心處理流程圖描述上面IPO表中所述核心操作的處理流程。根據表4-7，“選擇購買數量”這樣的步驟比較簡單，不需要進一步描述> 在上述IPO表中，對于“將該數量加入購買商品清單”的描述還不夠準確，將在下面的核心處理流程圖中進行說明，具體請參照圖4-8。圖4-8將該數量加入購買商品清單流程圖<以下4.2.2到4.2.12小節(jié)請參照4.2.1小節(jié)，給予補充說明>貨款支付功能結構設計功能設計訂單管理功能結構設計功能設計發(fā)貨信息管理功能結構設計功能設計退貨處理功能結構設計功能設計商品管理功能結構設計功能設計統(tǒng)計查詢功能結構設計功能設計商品發(fā)貨功能結構設計功能設計用戶管理功能結構設計功能設計日志管理功能結構設計功能設計系統(tǒng)角色管理功能結構設計功能設計用戶級別管理功能結構設計功能設計4.3數據庫設計主要實體屬性圖圖4-40商品類型實體屬性圖圖4-41商品信息實體屬性圖圖4-42購物車記錄實體屬性圖圖4-43訂單項實體屬性圖圖4-44訂單實體屬性圖圖4-45買家實體屬性圖圖4-46退貨申請實體屬性圖圖4-47支付記錄實體屬性圖圖4-48商品發(fā)貨記錄實體屬性圖圖4-49用戶實體屬性圖圖4-50日志實體屬性圖主要實體關系圖實體關系圖（E-R圖）圖4-51在線購物子系統(tǒng)E-R圖圖4-52系統(tǒng)管理子系統(tǒng)E-R圖主要數據庫表設計根據實體類，給出軟件系統(tǒng)主要庫表的設計，例如：（1）商品類別 保存商品類別的基本信息。表4-26商品類別表字段名數據類型長度主鍵否描述CategoryIdGuid主鍵商品類別IDCategoryNamenvarchar(20)20否商品類別名稱（2）商品信息 保存商品的基本信息。表4-27商品信息表字段名數據類型長度主鍵否描述IdGuid主鍵商品IDNamenvarchar(150)150否商品名稱Priceint否單價Amountint否庫存量Descriptionnvarchar(255)255否描述信息PhotoBinary否商品照片Categorynvarchar(50)50否商品類別Statusnvarchar(10)10否商品狀態(tài)（3）購物車記錄 保存購物車記錄的基本信息。表4-28購物車記錄表字段名數據類型長度主鍵否描述IdGuid主鍵購物車記錄IDOwnerIdGuid否購物車所有者IdGoodIdGuid否商品IdQuantityint否購買數量CreateDateDatetime否創(chuàng)建日期Moneyint否商品總額（4）訂單項 保存訂單項的基本信息。表4-29訂單項表字段名數據類型長度主鍵否描述OrderDetailIdGuid主鍵訂單項IDOrderIdGuid否訂單IDGoodIdGuid否商品IdQuantityint否購買數量Moneyint否商品總額（5）訂單 保存訂單的基本信息。表4-30訂單表字段名數據類型長度主鍵否描述IdGuid主鍵訂單IdUserIdGuid否客戶IdSumMoneyint否訂單總額OrderDateDatetime否下單日期PaymentStatuesnvarchar(10)10否支付狀態(tài)GoodsDeliverStatusnvarchar(10)10否發(fā)貨狀態(tài)EndDateDatetime否結單日期（6）用戶信息 保存用戶的基本信息。表4-31用戶信息表字段名數據類型長度主鍵否描述IdGuid主鍵用戶IDNamenvarchar(10)10否用戶姓名Codenvarchar(20)20否用戶CodePasswordnvarchar(20)20否密碼Mailnvarchar(50)50否電子郵件MobilePhonenvarchar(50)50否手機號碼Telnvarchar(50)50否座機號碼Addressnvarchar(255)255否發(fā)貨地址SexByte否性別（7）退貨申請