【正文】 都是很現(xiàn)實(shí)的問(wèn)題。開發(fā)一個(gè)基于web的動(dòng)態(tài)網(wǎng)上購(gòu)物系統(tǒng)，對(duì)發(fā)展電子商務(wù)無(wú)疑是十分迫切的。 問(wèn)題概述此處插入論文的論點(diǎn)，旨在突出論文討論解決的問(wèn)題。在信息技術(shù)日新月異的今天，隨著新技術(shù)、新功能的演變，開發(fā)一個(gè)XXX系統(tǒng)有著多種技術(shù)手段來(lái)實(shí)現(xiàn)。如何根據(jù)具體需求采用合適的技術(shù)來(lái)實(shí)現(xiàn)，是很多軟件開發(fā)者正在考慮的問(wèn)題。展開敘述一些傳統(tǒng)技術(shù)手段存在的問(wèn)題此外，現(xiàn)有的電子商務(wù)系統(tǒng)普遍存在著…….問(wèn)題，一直得不到解決。展開敘述一些傳統(tǒng)網(wǎng)上購(gòu)物系統(tǒng)普遍存在的問(wèn)題 研究的意義和重要性 研究的意義此處插入論文的研究意義， 研究的重要性此處插入研究的重要性， 研究的內(nèi)容和主要工作 研究的內(nèi)容此處插入研究的內(nèi)容，簡(jiǎn)要說(shuō)明論文中的系統(tǒng)采用了什么樣的技術(shù)手段，采用了什么樣的組織架構(gòu)，做了些什么研究工作，解決了哪些問(wèn)題 本人主要工作此處插入作者本人在項(xiàng)目中所負(fù)責(zé)或者完成的具體工作，簡(jiǎn)述作者本人所做的研究工作。此外，如果論文所述項(xiàng)目為集體合作，則應(yīng)該簡(jiǎn)略指出作者本人所負(fù)責(zé)的工作。以下為范本！ 在此項(xiàng)目中，本人做了如下工作：此處插入所做工作在項(xiàng)目開發(fā)中，本人主要負(fù)責(zé)系統(tǒng)需求分析、功能性分析、系統(tǒng)整體數(shù)據(jù)庫(kù)設(shè)計(jì)、主體框架設(shè)計(jì)搭建、WEB端程序開發(fā)，系統(tǒng)文檔撰寫、系統(tǒng)整體測(cè)試以及歷史數(shù)據(jù)導(dǎo)入等工作。 論文結(jié)構(gòu)此處插入該論文的整體結(jié)構(gòu)，簡(jiǎn)述論文的整體形式結(jié)構(gòu)，并簡(jiǎn)述每一章的主旨。以下為范本，請(qǐng)勿照搬！本文由五章內(nèi)容組成，其中：第一章介紹了本文的研究背景，對(duì)所需要解決的問(wèn)題進(jìn)行了概述，討論了項(xiàng)目的研究意義與重要性，闡述了論文的主要內(nèi)容以及本人的主要工作。第二章闡述的是本文所涉及到的開發(fā)方法及相關(guān)技術(shù)，包括：軟件工程開發(fā)模型、UML建模技術(shù)、數(shù)據(jù)庫(kù)技術(shù)等。第三章是本文的核心內(nèi)容之一，針對(duì)系統(tǒng)的業(yè)務(wù)需求、功能需求、數(shù)據(jù)需求和非功能需求等進(jìn)行了詳細(xì)分析，給出了主要的業(yè)務(wù)流程圖和用例圖，并對(duì)核心用例進(jìn)行了詳細(xì)描述，同時(shí)進(jìn)行了基礎(chǔ)數(shù)據(jù)的概念設(shè)計(jì)。第四章是本文的重點(diǎn)，在進(jìn)行了系統(tǒng)總體設(shè)計(jì)的基礎(chǔ)上，采用UML的包圖、類圖、順序圖和活動(dòng)圖等對(duì)系統(tǒng)的子模塊進(jìn)行了功能性詳細(xì)設(shè)計(jì)，并給出了主要功能的界面設(shè)計(jì)，同時(shí)通過(guò)實(shí)體類圖、ER圖和數(shù)據(jù)庫(kù)表結(jié)構(gòu)對(duì)數(shù)據(jù)庫(kù)進(jìn)行了詳細(xì)設(shè)計(jì)。第五章總結(jié)了本文所做的工作，同時(shí)對(duì)進(jìn)一步的工作進(jìn)行了展望。第二章 系統(tǒng)的開發(fā)方法及相關(guān)技術(shù)此處插入系統(tǒng)開發(fā)方法的統(tǒng)一概述，旨在簡(jiǎn)要的解釋系統(tǒng)開發(fā)的方法和涉及的相關(guān)技術(shù)。以下為范本，請(qǐng)勿照搬！本XXX系統(tǒng)采用基于XXX架構(gòu)，對(duì)應(yīng)使用XXX技術(shù)來(lái)展現(xiàn)其表示層，分別對(duì)不同需求的用戶服務(wù)，旨在最大程度滿足不同用戶的需求。服務(wù)層采用XXX技術(shù)來(lái)提供統(tǒng)一接口，降低其與其他系統(tǒng)間的耦合度，提供安全數(shù)據(jù)通信，提高系統(tǒng)可擴(kuò)展性、兼容性以及集成能力。……此處插入其他所采用的技術(shù)手段。 此外，系統(tǒng)采用增量模型進(jìn)行開發(fā)，以應(yīng)對(duì)不斷變化的需求，大量降低項(xiàng)目風(fēng)險(xiǎn)，保證系統(tǒng)核心功能，較快的交付可使用的模塊。以下幾個(gè)小節(jié)將根據(jù)以上統(tǒng)一概述，較為詳細(xì)的逐一展開進(jìn)行敘述，每一項(xiàng)具體開發(fā)方法或者相關(guān)技術(shù)的綜述獨(dú)立成為一個(gè)小節(jié)，每個(gè)小節(jié)下面具體有多少子小節(jié)并無(wú)具體規(guī)定，只要能講述清楚明白即可，以下為范本，請(qǐng)勿照搬！ 軟件工程開發(fā)模型 傳統(tǒng)瀑布模型瀑布模型(也稱為線性順序模型)，由溫斯頓羅伊斯在1970年提出，在20世紀(jì)80年代以前，瀑布模型一直都是唯一被廣泛采用的軟件開發(fā)模型。這個(gè)模型中，軟件生命周期中的制訂計(jì)劃，需求分析，軟件設(shè)計(jì)，程序編寫，軟件測(cè)試和運(yùn)行維護(hù)依次由上至下順序展開，如同瀑布流水，逐級(jí)下落，最終得到軟件產(chǎn)品。理想化的瀑布模型是單邊逐一而下的，認(rèn)為人在工作過(guò)程中不可能犯錯(cuò)誤。實(shí)際的瀑布模型是帶有反饋逐一而下的，當(dāng)后一階段發(fā)現(xiàn)前一階段的錯(cuò)誤時(shí)，可以修正前一階段的錯(cuò)誤繼續(xù)完成后一階段的任務(wù)。[1]瀑布模型的優(yōu)點(diǎn)：l 促進(jìn)軟件開發(fā)工程化，為項(xiàng)目提供了按階段劃分的檢查點(diǎn)l 降低軟件開發(fā)的復(fù)雜度，當(dāng)前一階段完成后，只需去關(guān)注后續(xù)階段l 可以在增量模型中使用瀑布模型瀑布模型的缺點(diǎn)：l 缺乏靈活性不適應(yīng)用戶需求的變化，項(xiàng)目的各個(gè)階段之間極少有反饋l 如果軟件需求不明確或者經(jīng)常變更需求，最終可能導(dǎo)致開發(fā)出的軟件與用戶預(yù)期的軟件不符，往往會(huì)導(dǎo)致大量的返工，有時(shí)甚至?xí)o開發(fā)人員帶來(lái)災(zāi)難性的后果，而這一點(diǎn)又常常在項(xiàng)目生命期的后期才有所覺(jué)察。 改進(jìn)的螺旋模型螺旋模型由巴利玻姆于1988年正式發(fā)表了軟件系統(tǒng)開發(fā)的“螺旋模型”，它是將瀑布模型與演化模型相結(jié)合，并且增加了兩者所忽略的風(fēng)險(xiǎn)分析，彌補(bǔ)了兩者的不足之處，該模型通常用來(lái)指導(dǎo)大型軟件項(xiàng)目的開發(fā)軟件項(xiàng)目的開發(fā)。軟件風(fēng)險(xiǎn)是任何軟件開發(fā)項(xiàng)目中都普遍存在的實(shí)際問(wèn)題，項(xiàng)目越大，軟件越復(fù)雜，承擔(dān)該項(xiàng)目所冒的風(fēng)險(xiǎn)也越大。軟件風(fēng)險(xiǎn)駕馭的目標(biāo)主要是在造成危害之前及時(shí)對(duì)風(fēng)險(xiǎn)進(jìn)行識(shí)別，分析，采取對(duì)策進(jìn)而消除或者減少風(fēng)險(xiǎn)的損害。螺旋模型將開發(fā)劃分為制訂計(jì)劃，風(fēng)險(xiǎn)分析，實(shí)施工程，客戶評(píng)估四類活動(dòng)。沿著螺旋線每旋轉(zhuǎn)一圈，表示開發(fā)出一個(gè)更完善的新的軟件版本，如果開發(fā)風(fēng)險(xiǎn)過(guò)大，開發(fā)機(jī)構(gòu)和客戶無(wú)法接受，項(xiàng)目就有可能就此終止。多數(shù)情況下，會(huì)沿著螺旋線繼續(xù)下去，自內(nèi)向外逐步延伸，最終得到滿意產(chǎn)品。螺旋模型開發(fā)的成敗很大程度上依賴于風(fēng)險(xiǎn)評(píng)估的成敗。沿著螺旋線旋轉(zhuǎn)，在笛卡爾坐標(biāo)的四個(gè)象限上分別表達(dá)了四類活動(dòng)：制定計(jì)劃：確定軟件目標(biāo)，選定實(shí)施方案，弄清項(xiàng)目開發(fā)的限制條件。風(fēng)險(xiǎn)分析：分析所選方案，考慮如何識(shí)別和消除風(fēng)險(xiǎn)。實(shí)施工程：實(shí)施軟件開發(fā)?？蛻粼u(píng)估：評(píng)價(jià)軟件功能和性能，提出修改建議。 []螺旋模型的優(yōu)點(diǎn)：l 設(shè)計(jì)上的靈活性,可以在項(xiàng)目的各個(gè)階段進(jìn)行變更。 　　l 以小的分段來(lái)構(gòu)建大型系統(tǒng),使成本計(jì)算變得簡(jiǎn)單容易。l 客戶始終參與每個(gè)階段的開發(fā),保證了項(xiàng)目不偏離正確方向以及項(xiàng)目的可控性。l 隨著項(xiàng)目推進(jìn),客戶始終掌握項(xiàng)目的最新信，從而他或她能夠和管理層有效地交互。l 客戶認(rèn)可這種公司內(nèi)部的開發(fā)方式帶來(lái)的良好的溝通和高質(zhì)量的產(chǎn)品。螺旋模型的缺點(diǎn)：l 很難讓用戶確信這種演化方法的結(jié)果是可以控制的。l 建設(shè)周期長(zhǎng)，而軟件技術(shù)發(fā)展比較快，所以經(jīng)常出現(xiàn)軟件開發(fā)完畢后，和當(dāng)前的技術(shù)水平有了較大的差距，無(wú)法滿足當(dāng)前用戶需求。 面向?qū)ο蟮膰娙Ｐ驮诿嫦驅(qū)ο蟮姆椒ㄖ?，提出了于瀑布模型相?duì)應(yīng)的噴泉模型，該模型的主要特點(diǎn)是認(rèn)為軟件生命周期的各個(gè)階段是相互重疊和多次反復(fù)的，它是一種以用戶需求為動(dòng)力，以對(duì)象為驅(qū)動(dòng)的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過(guò)程。噴泉模型不像瀑布模型那樣，需要分析活動(dòng)結(jié)束后才開始設(shè)計(jì)活動(dòng)，設(shè)計(jì)活動(dòng)結(jié)束后才開始編碼活動(dòng)。該模型的各個(gè)階段沒(méi)有明顯的界限，開發(fā)人員可以同步進(jìn)行開發(fā)。其優(yōu)點(diǎn)是可以提高軟件項(xiàng)目開發(fā)效率，節(jié)省開發(fā)時(shí)間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過(guò)程。由于噴泉模型在各個(gè)開發(fā)階段是重疊的，因此在開發(fā)過(guò)程中需要大量的開發(fā)人員，因此不利于項(xiàng)目的管理。此外這種模型要求嚴(yán)格管理文檔，使得審核的難度加大，尤其是面對(duì)可能隨時(shí)加入各種信息、需求與資料的情況。噴泉一詞本身就體現(xiàn)了迭代和無(wú)間隙的特性。[1]噴泉模型的優(yōu)點(diǎn)：軟件項(xiàng)目開發(fā)效率高，節(jié)省開發(fā)時(shí)間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過(guò)程。噴泉模型不像瀑布模型那樣，需要分析活動(dòng)結(jié)束后才開始設(shè)計(jì)活動(dòng)，設(shè)計(jì)活動(dòng)結(jié)束后才開始編碼活動(dòng)。該模型的各個(gè)階段沒(méi)有明顯的界限，開發(fā)人員可以同步進(jìn)行開發(fā)。噴泉模型的缺點(diǎn)：由于噴泉模型在各個(gè)開發(fā)階段是重疊的，因此在開發(fā)過(guò)程中需要大量的開發(fā)人員，因此不利于項(xiàng)目的管理。此外這種模型要求嚴(yán)格管理文檔，使得審核的難度加大，尤其是面對(duì)可能隨時(shí)加入各種信息、需求與資料的情況。形式化方法模型包含了一組活動(dòng)，他們導(dǎo)致了計(jì)算機(jī)軟件的數(shù)學(xué)規(guī)約。形式化方法使得軟件工程師們能夠通過(guò)應(yīng)用一個(gè)嚴(yán)格的數(shù)學(xué)符號(hào)體系來(lái)規(guī)約、開發(fā)、和驗(yàn)證基于計(jì)算機(jī)的系統(tǒng)。在開發(fā)中使用形式化方法時(shí)，它們提供了一種機(jī)制，能夠消除使用其它軟件過(guò)程模型難以克服的很多問(wèn)題。二義性、不完整性、不一致性能被更容易地發(fā)現(xiàn)和糾正，而不是通過(guò)專門的評(píng)審，是通過(guò)對(duì)應(yīng)用的數(shù)學(xué)分析。 形式化方法提供了可以產(chǎn)生無(wú)缺陷軟件的承諾。 UML建模技術(shù) UML語(yǔ)言和要素UML（Unified Modeling Language）統(tǒng)一建模語(yǔ)言,是用來(lái)對(duì)軟件密集型系統(tǒng)進(jìn)行可視化建模的一種通用語(yǔ)言。UML被廣泛應(yīng)用于數(shù)據(jù)建模，業(yè)務(wù)建模，對(duì)象建模，組件建模等。UML與具體的程序設(shè)計(jì)語(yǔ)言無(wú)關(guān)，它只是一種建模語(yǔ)言而不是一種方法學(xué)，和其它的計(jì)算機(jī)語(yǔ)言一樣，也是由基本詞匯和語(yǔ)法兩個(gè)部分構(gòu)成。UML定義了一些建立模型、表達(dá)某種特定含義所需要的基本元素，這些元素稱為元模型，相當(dāng)于語(yǔ)言中的基本詞匯，例如用例、類等。在此基礎(chǔ)上，還定義了這些元模型互相之間關(guān)系的規(guī)則，以及如何用這些元素和規(guī)則繪制圖形以建立模型來(lái)映射現(xiàn)實(shí)世界，這些規(guī)則和圖形稱為UML模型表示法或圖示。UML正處于不斷演化和完善過(guò)程之中，最初的UML標(biāo)準(zhǔn)只是作為一種面向?qū)ο筝o助的工具而設(shè)計(jì)的，即為軟件的設(shè)計(jì)意圖提供一種非形式化的捕獲和表達(dá)手段和工具。因此，早期UML版本中存在著的一些因UML工具廠商不同而引入的分歧和模糊定義，正隨著UML標(biāo)準(zhǔn)的演化而被逐步消除，讓其向著成為一種形式化建模語(yǔ)言規(guī)范的方向不斷演化。與此同時(shí)，UML也正在變得越來(lái)越龐大，但當(dāng)我們只是運(yùn)用UML來(lái)進(jìn)行面向?qū)ο笤O(shè)計(jì)時(shí)，并不需要用到所有的UML內(nèi)容，而是可以學(xué)習(xí)和使用UML那些最適合的部分。 常用的UML模型圖 用例圖用例圖用來(lái)描述軟件需求模型中的系統(tǒng)功能，通過(guò)一組用例可以描述軟件系統(tǒng)能夠給用戶提供的功能。用例圖可以作為整個(gè)系統(tǒng)開發(fā)過(guò)程中的開發(fā)依據(jù)，指導(dǎo)和驅(qū)動(dòng)其他模型。 類圖類圖(Class Diagram)是由類、相關(guān)建模元素及其關(guān)系構(gòu)成的圖，用來(lái)描述類之間的靜態(tài)關(guān)系。類圖在系統(tǒng)中處在核心位，也是UML中最為重要的一種圖。在系統(tǒng)的不同開發(fā)階段，類圖可以具有不同的抽象程度。隨著開發(fā)的深入，類圖應(yīng)該越來(lái)越詳細(xì)、具體。類圖可以分為：界面類、控制類和實(shí)體類。l 界面類位于系統(tǒng)與外界的交界處，承擔(dān)系統(tǒng)與外界的信息功能。界面類處在用例圖中參與者與用例的關(guān)聯(lián)處，可以根據(jù)用例圖發(fā)現(xiàn)界面類。在界面類的設(shè)計(jì)中主要關(guān)注屬性和消息方法；l 控制類承擔(dān)著事務(wù)處理，控制調(diào)控的控制作用。一個(gè)用例中最少會(huì)有一個(gè)控制類，用來(lái)控制用例中的事件順序，也可以在多個(gè)用例之間協(xié)調(diào)用例之間的聯(lián)系。在控制類的設(shè)計(jì)中主要關(guān)注類的方法。l 實(shí)體類對(duì)應(yīng)著現(xiàn)實(shí)中的客觀實(shí)物，用來(lái)保存信息，一般對(duì)應(yīng)著數(shù)據(jù)表、文件等。在實(shí)體類的設(shè)計(jì)中主要關(guān)注類的屬性； 交互圖交互圖 用來(lái)描述對(duì)象之間,以及對(duì)象與參與者之間的動(dòng)態(tài)協(xié)作關(guān)系以及協(xié)作過(guò)程中行為次序的圖形文檔。交互圖的類型包含順序圖和協(xié)作圖，其作用是分析為了實(shí)現(xiàn)一個(gè)用例的功能所參與的對(duì)象，以及這些對(duì)象相互之間的動(dòng)態(tài)消息聯(lián)系。 活動(dòng)圖活動(dòng)圖是UML的動(dòng)態(tài)視圖之一，用來(lái)描述事物或?qū)ο蟮幕顒?dòng)變化流程。活動(dòng)圖可以用來(lái)：l 描述工作流或者業(yè)務(wù)流程；l 描述工程組織過(guò)程；l 描述算法流程。 數(shù)據(jù)庫(kù)技術(shù) 數(shù)據(jù)庫(kù)范式關(guān)系數(shù)據(jù)庫(kù)中的關(guān)系必須滿足一定的要求，即滿足不同的范式。目前關(guān)系數(shù)據(jù)庫(kù)有六種范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。滿足最低要求的范式是第一范式（1NF）。在第一范式的基礎(chǔ)上進(jìn)一步滿足更多要求的稱為第二范式（2NF），其余范式以次類推。一般說(shuō)來(lái)，數(shù)據(jù)庫(kù)只需滿足第三范式（3NF）就行了。第一范式（1NF）。所謂第一范式（1NF）是指數(shù)據(jù)庫(kù)表的每一列都是不可分割的基本數(shù)據(jù)項(xiàng)，同一列中不能有多個(gè)值，即實(shí)體中的某個(gè)屬性不能有多個(gè)值或者不能有重復(fù)的屬性。如果出現(xiàn)重復(fù)的屬性，就可能需要定義一個(gè)新的實(shí)體，新的實(shí)體由重復(fù)的屬性構(gòu)成，新實(shí)體與原實(shí)體之間為一對(duì)多關(guān)系。在第一范式（1NF）中表的每一行只包含一個(gè)實(shí)例的信息。簡(jiǎn)而言之，第一范式就是無(wú)重復(fù)的列。第二范式（2NF）。第二范式（2NF）是在第一范式（1NF）的基礎(chǔ)上建立起來(lái)的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范