【正文】 當訂單表插入成功，訂單子項表插入失敗時，對訂單表進行的操作如下面 sql 語句所示。為保持消費者在線瀏覽信息的一致性，手機表中相應(yīng)手機的數(shù)量也要做庫存減少的調(diào)整。 (i)。i()。 for(int i=0。在更改的具體函數(shù)實現(xiàn)中，首先 要對更改的數(shù)量與庫存數(shù)量的值進行比較，看是否庫存手機數(shù)量已經(jīng)不足購買要求，如果是，則給出提示。其中首先通過 session 變量獲取購物車中的信息。 對于購物車的實現(xiàn)本系統(tǒng)主要采用用 session保存一次會話中的購買信息，最后將 session 中的信息一次性提交，即購物車的提交，然后將提交的信息以訂單的形式保存到數(shù)據(jù)庫中。一個不能進行銷售的系統(tǒng)是無法稱其為銷售系統(tǒng)的，所以如何完成消費者購買手機的操作過程成為了重點。 Op_telephone 類和 Op_shopercar 類是 operation 包中的兩個關(guān)鍵的類，也是系統(tǒng)功能實現(xiàn)的關(guān)鍵類。然后通過將得到的參數(shù)值與數(shù)據(jù)庫中存儲的信息進行比較，來確定數(shù)據(jù)庫中是否含有此記錄，即可達到登錄信息是否正確的驗證操作。主要包括管理員登錄信息驗證。此包中其它類圖結(jié)構(gòu)均與此類似。 Leaguer 是對會員實體的抽象描述。 Admin 類是對管理員實體的抽象描述。 TimeP 為一個獲取本地系統(tǒng)時間功能的類，主要用于系統(tǒng)數(shù)據(jù)庫某些表中日期型字段初始值的獲取。系統(tǒng)包圖如圖44 所示。 (newtelephone)。 ()。 Vector 類型變量與得到數(shù)據(jù)庫中信息的結(jié)果集 ResultSet 的交互過程如圖 43 所示： 37 圖 43 Vector 在本系統(tǒng)中的工作機制 下面是一個用 Vector 來保存搜索信息的一個函數(shù)，從中可以體現(xiàn)對 Vector 的使用方法。而 Vector 中存儲的元素還可以通過 elementAt()函數(shù)簡單的獲得，從而能方便在所需要的地方進行使用。 Vector 的最大特點是它只儲存對象的引用，而不是實際的對象。 Vector 是 Java 中的一 個工具類。通過當前頁號，和每頁要顯示的記錄，在根據(jù)總的記錄數(shù)，就可以完成對每個單頁中要顯示的具體信息記錄的定位。在下面通過當前要顯示的頁面號來判斷在數(shù)據(jù)庫中第一個要顯示的記錄號和最后一個要顯示的記錄號。 } } 對于 GBK 到 ISO 88591的轉(zhuǎn)換方法限于篇幅，此處略去，可在源程序中找到。 if(null==strIn || (().equals())){ return strIn。由于在整個手機銷售系統(tǒng)中操作均是在 WEB 頁面上完成，而同時又多是和數(shù)據(jù)庫的交互，所以需要這種編碼轉(zhuǎn)換的地方很多。由于在 jsp 頁面中使用了語句 % page contentType=text/html。 整個系統(tǒng)中表單的提交或是 URL 傳參數(shù)值時都是依照 WEB 容器在其內(nèi)部默認的字符編碼格式 ISO 88591來進行處理的。 ISO/IEC 88591，又稱 Latin1 或“西歐語言”，是 國際化標準組織 內(nèi) ISO/IEC 8859 的第一個 8位字符集。但隨著計算機技術(shù)的發(fā)展，和計算機的普及，為了適應(yīng)世界各地對字符集的不同要求， Unicode編碼應(yīng)運而生了。亂碼問題則成為系統(tǒng)開發(fā)整個過程中一個讓人頭疼的問題。這樣大大減少了代碼重用時需要作的工作。同時考慮到系統(tǒng)的移植性和可擴展行，將與數(shù)據(jù)庫的連接操作封裝到了相應(yīng)的 Javabean 里，從而在系統(tǒng)改變與數(shù)據(jù)庫的連接方式時僅需修改一下此 bean 中的代碼即可。 本系統(tǒng)采用的數(shù)據(jù)庫系統(tǒng)是 MS SQL Server 2021 系統(tǒng)。 表 35 消費者 (Customer) 字段名 說 明 類 型 長 度 可否為 空 主鍵 a_id 管理員帳號 字符型 20 否 是 a_password 管理員密碼 字符型 20 否 上節(jié)中提到的各表關(guān)系如圖 33所示。 表 33 訂單表 (teleorder) 字段名 說 明 類 型 長 度 可否為 空 主鍵 29 o_id 訂單編號 整型 4 否 是 l_id 下單會員帳號 字符型 20 否 o_time 下訂單時間 日期型 8 否 o_price 訂單總金額 浮點型 8 否 o_content 訂單備注 文本型 16 是 o_isdeal 訂單是否被處理標識 字符型 1 否 訂單明細表：用來描述每一訂單中的詳細訂購信息。 o_isdeal 是標識此訂單是否已經(jīng)處理。其中公司 id字段從 c_id 為手機表的外鍵，并也設(shè)置成為標識列，從而以便于管理和維護。標識列即為由用戶創(chuàng)建，由系統(tǒng)管理，每增加一條記錄，則其自動增加，用戶不可對其進行操作，在過程中若有記錄被刪除，其不進行縮進，仍保留原有值，并一直自增。本系統(tǒng)的實體－關(guān)系模型如圖 32所示。 26 如果實體已經(jīng)是第二范式的，并且如果它的非主鍵屬性的值不依賴于任何其它非主鍵屬性，則這個實體是第三范式的。規(guī)范化是一種數(shù)據(jù)分 析技術(shù)，該技術(shù)組織數(shù)據(jù)屬性以便他們可以組合起來形成無冗余的，穩(wěn)定的，靈活的并具有適應(yīng)性的實體。 SQL 集成實現(xiàn)了數(shù)據(jù)庫生命周期中的全部操作。關(guān)系數(shù)據(jù)模型提供了關(guān)系操作的特點和功能要求，但不對 DBMS 的語言給出具體的語法要求。用戶在對這兩種數(shù)據(jù)庫進行存取時，仍然需要明確數(shù)據(jù)的存儲結(jié)構(gòu)，指出存取路徑?，F(xiàn)實世界中很多事物是按層次組織起來的。網(wǎng)狀數(shù)據(jù)庫的數(shù)據(jù)項可以是多值的和復(fù)合的數(shù)據(jù)。數(shù)據(jù)庫與信息系統(tǒng)的基本關(guān)系描述如圖 31 所示。 數(shù)據(jù)庫概述 電子計算機數(shù)據(jù)庫系統(tǒng)的萌芽出現(xiàn)于上個世紀 60年 代。數(shù)據(jù)庫是本系統(tǒng)三層結(jié)構(gòu)設(shè)計模式的最底層，也是整個系統(tǒng)運行時的核心部分。因此在整個系統(tǒng)的 WEB 頁面的設(shè)計中使用了 CSS 樣式表，來控制整個 22 系統(tǒng)的顯示風(fēng)格。如圖中所示，在進入各個頁面后，可以對相應(yīng)的各項信息進行管理。只有會員經(jīng)過登錄或注冊進入到主界面，才可以正常使用系統(tǒng)的功能。才可以進一步的體現(xiàn)系統(tǒng)的功能和優(yōu)勢。本系統(tǒng)采用 SQL Server 2021 作為后臺數(shù)據(jù)庫 .利用 Sun公司的 JDBCODBC bridge 進行數(shù)據(jù)庫的連接 ,對數(shù)據(jù)庫的 操作 (打開 、 查詢 、 修改 、 刪除等 )封裝在相應(yīng)的 bean 中，負責(zé)與數(shù)據(jù)庫的交互以及數(shù)據(jù)提取等。比如我們編寫 SQLwinForm或 WEB 應(yīng)用的時候，和數(shù)據(jù)庫連接的時候就要輸入用戶名和密碼，如果只用兩層結(jié)構(gòu)，就有安全的問題，如果我們編寫一個邏輯層， 19 把連接這一部份處理在中間層（比如該層處理連接池和安全審核），就不用擔(dān)心對方反編譯我們用中間語言生成的程序。數(shù)據(jù)如何存貯和管理，這都是數(shù)據(jù)層首先要考慮的問題。三層結(jié)構(gòu)框架在邏輯上分為：客戶服務(wù)層，業(yè)務(wù)服務(wù)層，數(shù)據(jù)服務(wù)層。而 JSP，即 Java Sever Pages 是 Sun公司推出的一種執(zhí)行于服務(wù)器端的動態(tài)網(wǎng)頁開發(fā)技術(shù)。 ASP，即Active Secver Page，是 Microsoft 開發(fā)的動態(tài)網(wǎng)頁語言，采用腳本語言 VBScript 作為自己的開發(fā)語言。 系統(tǒng)開發(fā)技術(shù)方案 本手機在線銷售系統(tǒng)是基于三層結(jié)構(gòu) B/S 架構(gòu)模式設(shè)計的，采用 JSP 進行實現(xiàn)。 ○ 2 系統(tǒng)給出訂單信息反饋。管理員可以逐一查看訂單的基本信息和詳細信息。 訂單信息維護用例完成管理員對系統(tǒng)運行過程中會員所下訂單的維護。 主要事 件流程： 角色動作 系統(tǒng)響應(yīng) ○ 1 填寫手機信息表單。手機添加用例文檔見表 27。 ○ 2 系統(tǒng)等待會員輸入查詢條件。 表 26 手機查詢用例詳細描述 用例名稱： 手機查詢 用例 ID： 106 角色： Leaguer 基本描述： 此用例完成會員對本系統(tǒng)中的產(chǎn)品的信息的快速查看。 ○ 2 系統(tǒng)驗證購物車信息是否正確，驗證會員是否登錄，如果驗證合法，完成購物車的提交操作，否則給予錯誤提示。 表 25 提交購物車用例詳細描述 用例名稱： 提交購物車 用例 ID： 105 角色： Leaguer 基本描述： 此用例的前提條件為會員成功的登錄，并正確的完成了添加購物車等操作。 ○ 3 會員對手機購買數(shù)量進行修改。 表 24 修改購物車用例詳細描述 用例名稱： 修改購物車 用例 ID： 104 角色： Leaguer 基本描述： 此用例的前提條件為會員成功的添加了購物車，在購物車界面中會員可以對其購買的手機的數(shù)量進行相應(yīng)的修改。與本用例相關(guān)的角色為 Leaguer。 主要事 件流程： 角色動作 系統(tǒng)響應(yīng) ○ 1 會員進行信息的更新。會員信息更新用例文檔見表 22。 ○ 2 系統(tǒng)等待角色輸入登錄信息。登錄用例文檔見表 21。訂單信息處理模塊 13 也包括對訂單信息和訂單明細的維護操作，但主要功能體現(xiàn)在對用戶訂單的查詢，即對用戶所下的訂單進行相應(yīng)的處理即反饋。手機購買信息被保存在當前的會話當中，用戶可以繼續(xù)購買商品，繼而添加購物車，最后可以對購買數(shù)量進行相應(yīng)的修改，也可對相應(yīng)的購買子項進行刪除或清空購物車等操作 ，并最終提交購物車，從而完成一次購買的全過程。 會員具有的核心操作功能是購買手機，即與購物車有關(guān)的所有操作模塊。根據(jù)會員的具體需求輸入手機的型號或者價格限定，可以在系統(tǒng)信息庫中快速便捷的查詢到滿足自己需求的手機。 圖 25 系統(tǒng)用例圖 系統(tǒng)用 例分析 整個在線手機銷售系統(tǒng)中存在管理員和會員兩個角色，會員和 12 管理員通過 WEB 頁登錄本系統(tǒng)后，可以完成各自相應(yīng)的功能操作。 圖 23 手機銷售系統(tǒng)總體圖 10 圖 24 手機銷售系統(tǒng)零級圖 系統(tǒng)數(shù)據(jù)流程圖零級圖 根據(jù)數(shù)據(jù)流程總體圖，將各部分數(shù)據(jù)流程進行細化，可得手機銷售系統(tǒng)數(shù)據(jù)流程零級圖。據(jù)此對投資和收益的權(quán)衡比較，確定本手機銷售系統(tǒng)具有經(jīng)濟可行性。所以綜合這些方面，本手機銷售系統(tǒng)滿足技術(shù)可行性。 Html， 9 JSP 及 ASP 等技術(shù)對 WEB 頁面的開發(fā)都有較好的支持。鑒于本系統(tǒng)的規(guī)模運行可行性和進度可行性都可以滿足。 運行可行性是對方案在組織中的合適程度的度量，它也是就人們對該系統(tǒng)的感覺的度量。 21 網(wǎng)上購物基本流程 管理員作為系統(tǒng)中的另一個主要角色，負責(zé)整個電子商務(wù)網(wǎng)站 8 的維護和用戶購買信息的管理和反饋。然后根據(jù)自己的實際需求來瀏覽自己所需要的商品。 7 第 2 章 系統(tǒng)分析及設(shè)計 任務(wù)概述 首先本系統(tǒng)的角色有兩個，即消費者和管理員。用戶可以對商品進行瀏覽，搜索以來了解具體手機的詳細信息。不用去做，就是想一下，也覺得有些不舒服吧。 本手機銷售系統(tǒng)概述 手機作為 21 世紀的重要通訊工具，對人們生活的改變和影響，是人所共睹的。 貼 近客 戶 需求 優(yōu)勢 ：某些公司在 時 機成熟 時 ，逐 漸 提供了下列服 務(wù) ：公司所有的商品， 實時 的、個性化的交互式 導(dǎo)購員 ，以及“大家一起 購 物”（能 夠 使不同地點 顧 客在網(wǎng)上交 談 ）系 統(tǒng) 和 購 物廣告。 客 戶 忠 誠 度 優(yōu)勢 ：有一 項調(diào) 研 顯 示 ：客 戶對 網(wǎng) 絡(luò) 的品牌知名度的 認 同感要超 過對傳統(tǒng) 行 業(yè) 。電子商務(wù)發(fā)展到今天，除了網(wǎng)上零售活動之外， B2C 已發(fā)展至包括網(wǎng)上銀行、旅行、拍賣、保健信息以 及房地產(chǎn)業(yè)務(wù)等多項服務(wù) [2]。 美國 9雖然歐洲的電子商務(wù)比美國起步晚了近 18 個月，但發(fā)展也很快。 正是這些優(yōu)勢的存在電子商務(wù)自他誕生之日起發(fā)展到現(xiàn)在，各個方面都有了較大的完善，并且隨著互聯(lián)網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，網(wǎng)上購物商城的數(shù)量也不斷增加。 隨著電子商務(wù)的日益成熟， B2C 模式的電子商務(wù)正與人們的生活結(jié)合的越來越緊密。尤其是隨著 INTERNET 技術(shù)的日益成熟，電子商務(wù)真正的發(fā)展將是建立在INTERNET 技術(shù)上的。顧名思義，其內(nèi)容包含兩個方面，一是電子方式，二是商貿(mào) 活動。頻繁的更新?lián)Q代，給人們的選購也帶來了很大的不便，而通過前面的介紹和分析，電子商務(wù)正是解決這個問題的很好方案。這個技術(shù)還在不斷的更新和優(yōu)化。電子商務(wù)正改變著企業(yè)經(jīng)營的方式。電子商務(wù)（ EBusiness）的概念也隨著網(wǎng)絡(luò)的發(fā)展被人 們所了解。 因此，根據(jù)電子商務(wù)的基本 要求，本文通過分析網(wǎng)上購物的業(yè)務(wù)流程及其特點，對本在線手機銷售系統(tǒng)流程進行了詳細設(shè)計和模塊劃分，根據(jù)實際需求，合理的構(gòu)建了數(shù)據(jù)庫，并利用了目前主流的 WEB 開發(fā)技術(shù)－ JSP，采用三層結(jié)構(gòu)思想來進行本系統(tǒng)的實施。作為 21 世紀網(wǎng)絡(luò)應(yīng)用和貿(mào)易方式的代表，電子商務(wù)的應(yīng)用和推廣將給社會和經(jīng)濟帶來極大的效益，并將成為全球經(jīng)濟的最大增長點之一。正因為電子商務(wù)有著誘人的前景和廣闊的發(fā)展空間，所以越來越受到人們的關(guān)注和了解。最終以程序的形式實現(xiàn)了在線手機銷售系統(tǒng)的各個主要功能模塊，完成了用戶購物車的提交，商品的查詢，以及管理員對整個系統(tǒng)的信息維護等功能。 過去一提到商務(wù)，人們不是聯(lián)想到在一家商場中精疲力盡地尋找自己所需的商品，就是聯(lián)想到在談判桌前，買賣雙方唇槍舌劍地