【正文】 任務(wù)：分析員通過需求分析提供一種可轉(zhuǎn)化為數(shù)據(jù)設(shè)計 、 結(jié)構(gòu)設(shè)計和過程設(shè)計的數(shù)據(jù)與功能表示 ， 在軟件完成后 ， 需求分析階段研究的對象是軟件項目的用戶需求 。 問題識別就是從系統(tǒng)角度來理解軟件 ， 確定對所開發(fā)系統(tǒng)的綜合要求 ，并提出這些需求的實現(xiàn)條件 ， 以及需求應(yīng)該達(dá)到的標(biāo)準(zhǔn) 。 分析與綜合逐步細(xì)化所有的軟件功能 ， 找出系統(tǒng)各元素間的 聯(lián)系 ， 接口特性和設(shè)計上的限制 ， 分析他們是否滿足需求 ， 剔除不合理部分 ， 增加需要部分 。 制訂規(guī)格說明書即編制文檔 ， 描述需求的文檔稱為軟件需求規(guī)格說明書 。 評審對功能的正確性 ， 完整性和清晰性 ， 以及其它需求給予評價 。 10 需求層次 軟件需求包括三個不同的層次 ——業(yè)務(wù)需求 、 用戶需求和功能需求 ， 也包括非功能需求 。 用戶需求（ user requirement）文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù) ， 這在用例（ use case）文檔或方案腳本（ scenario）說明中予以說明 。 軟件需求各組成部分之間的關(guān)系 ， 如圖 31 所示 。 在該階段需求分析人員需要確定整個產(chǎn)品的功能要求 ， 并且將現(xiàn)實事務(wù)抽象成對象并建模 。 而需求分析的任務(wù)是定義待開發(fā)的軟件的功能 、 性能等指標(biāo) 。 也許用戶列舉了查詢 、 訂購 、 下訂單 、 商品管理 、 用戶管理和訂單管理 ， 也許還有自己有特色的東西 。 其次要分析用戶的業(yè)務(wù)流程 ， 前面了解的用戶業(yè)務(wù)只是一些離散的業(yè)務(wù)活動 ， 而業(yè)務(wù)流程是一種重要的信息 ， 比如用戶購買商品這個流程 ， 它需要經(jīng)歷商品查詢 、 加入購物車 、 查詢購物車 、 結(jié)算（包括填寫訂購人詳細(xì)信息 、送貨方式和支付方式） 、 訂單確認(rèn) 、 送貨到收貨等一系列活動 ， 然后將了解到的用戶 活動加以整理并按照這些活動所固有的次序形成業(yè)務(wù)流程 。 數(shù)據(jù)流圖 系統(tǒng)數(shù)據(jù)流圖如圖 32 所示 。 它主要是對數(shù)據(jù)流圖中的數(shù)據(jù)流 、 處理邏輯 、 外部實體 、 數(shù)據(jù)存儲和數(shù)據(jù)項等方面進(jìn)行具體的定義 。 本系統(tǒng)數(shù)據(jù)項如 表 31 所示 。 本系統(tǒng)的需求分析的任務(wù)是通過對系統(tǒng)使用者 ， 即顧客購物的需求進(jìn)行分 析 ， 來完成下一階段的系統(tǒng)的數(shù)據(jù)結(jié)構(gòu) 、 功能模塊等的設(shè)計工作 。 其中的用戶需求就是市場的需求 ， 它是需求分析階段最重要的工作 。 鑒于網(wǎng)上商 城 系統(tǒng)的兩種用戶角色的說明 ， 可將系統(tǒng)分為前臺和后臺 ，這種分法也是當(dāng)前網(wǎng)站系統(tǒng)慣用的做法 。 該后臺系統(tǒng)包括七大基本模塊：使用幫助 、 訂單管理 、 數(shù)碼管理 、 管理用戶 、 數(shù)碼分類 、 網(wǎng)站廣告管理 、 網(wǎng)站信息管理 。 層次方框圖是用樹形結(jié)構(gòu)的一系列多層次的矩形框描繪數(shù)據(jù)的層次結(jié)構(gòu) 。 隨著結(jié)構(gòu)的精細(xì)化 ， 層次方框圖對數(shù)據(jù)結(jié)構(gòu)也描繪得越來越詳細(xì) ， 這種模式非常適合于需求分析階段的需要 。 前臺文件結(jié)構(gòu)圖如圖 41 所示 。 后 臺 系 統(tǒng)訂單管理管理用戶使用幫助數(shù)碼分類管理數(shù)碼管理網(wǎng)站后臺管理網(wǎng)站信息管理返回首頁注銷登陸未處理訂單正處理訂單管理后臺管理員管理網(wǎng)站用戶查詢商品添加商品添加廣告已處理訂單查詢廣告 圖 42 后臺文件結(jié)構(gòu)圖 數(shù)據(jù)庫設(shè)計 數(shù)據(jù)庫技術(shù)的 概念描述 數(shù)據(jù)庫技術(shù)是計算機科學(xué)技術(shù)中發(fā)展最快的領(lǐng)域之一 ， 也是應(yīng)用最廣的技術(shù)之一 ， 它已成為計算機信息系統(tǒng)與應(yīng)用系統(tǒng)的核心技術(shù)和重要基礎(chǔ) 。 數(shù)據(jù)是按一定的格式存放的 。 數(shù)據(jù)庫中的數(shù)據(jù)按一定的數(shù)據(jù)模型組織 、 描述和儲存 ， 具有較小的冗余度 、 較高的數(shù)據(jù)獨立性和易擴展性 ， 并可為各種用戶共享 。 建立一個滿足各級部門信息處理要求的行之有效的信息系統(tǒng)也成 為一個企業(yè)或者組織生存和發(fā)展的重要條件 。 對于一個國家來說 ， 數(shù)據(jù)庫的建設(shè)規(guī)模 、 數(shù)據(jù)庫信息量的大小和使用頻率 已 成為衡 17 量這個國家信息化程度的重要標(biāo)志 。 他是數(shù)據(jù)庫系統(tǒng)的一個重要組成部分 ， 其主要功能包括以下幾個方面： 1． 數(shù)據(jù)定義功能 DBMS 提供數(shù)據(jù)定義語言（ DDL） ， 用戶通過它可以方便地對數(shù)據(jù)庫中的數(shù)據(jù)對象進(jìn)行定義 。 3． 數(shù)據(jù)庫的運行管理 數(shù)據(jù)庫在建立 、 運用和維護(hù)時由數(shù)據(jù)庫管理系統(tǒng)統(tǒng)一管理 、 統(tǒng)一控制 ，以保證數(shù)據(jù)的安全性 、 完整性 、 多用戶對數(shù)據(jù)的并發(fā)使用及發(fā)生故障后 的系統(tǒng)恢復(fù) 。 數(shù)據(jù)庫的需求分析 數(shù)據(jù)項和數(shù)據(jù)結(jié)構(gòu)如下： 公告信息表（ Board）：公告編號 ， 公告標(biāo)題 ， 公告信息 ， 提交時間 ， 提交人 。 商品信息表（ Goods）：商品編號 ， 商品名稱 ， 商品廠家 ， 商品品牌 ， 商品進(jìn)貨價格 ， 商品零售價格 ， 商品庫存數(shù)量 ， 商品銷售數(shù)量 ， 商品售出時間 。 用戶表（ Users）：用戶名 ， 用戶登陸名 ， 用戶密碼 ， 用戶郵件 ， 用戶地址 。 訂單表（ order_table）：訂單號 ， 用戶 ID， 訂單產(chǎn)生日期 ， 訂單是否確認(rèn) ，訂單處理人 ， 訂單發(fā)送狀態(tài) ， 訂單接收人姓名 ， 訂單接收地址 ， 訂單接收地址編碼 ， 訂單總價 。 2． 屬性：用橢圓表示 ， 并用無向邊將其與相應(yīng)的實體連接起來 。 本系統(tǒng)的 ER 圖如 圖 43 所示 。 表 41 UserOrder_table（用戶訂單表） 序號 英文名 中文名 類型 長度 (字符 ) 1 Ordered 訂單號 Varchar 20 20 2 UserId 訂購人 ID Smallint 2 3 OrderTime 訂單產(chǎn)生日期 Datetime 8 4 OrderStatus 訂單是否確認(rèn) Int 2 5 OrderPassTime 確認(rèn)時間 Datatime 8 6 OrderPassId 訂單處理人 Smallint 2 7 OrderSendState 訂單發(fā)送狀態(tài) Int 4 8 OrderRecName 訂單接收人姓名 Varchar 10 9 OrderRecAddrss 訂單接收地址 Varchar 200 10 OrderPecZip 訂單接收地址編 碼 Float 10 11 OrderTotalPrice 訂單總價 Int 10 本章小結(jié) 總體設(shè)計階段 ， 在需求分析的基礎(chǔ)之上規(guī)劃出了系統(tǒng)的功能模塊 ， 以及在此分析基礎(chǔ)上設(shè)計出的具體的 、 可以滿足本系統(tǒng)全部需求的數(shù)據(jù)庫 。 21 第 5 章 詳細(xì)設(shè)計 系統(tǒng)運行平臺設(shè)置 1． 硬件環(huán)境：臺式計算機（ PC）一臺 ， 如表 51 所示 。 購物車 在這里 ， 我先介紹一下購物車的主要表現(xiàn)為：用戶信息和權(quán)限相關(guān)功能的實現(xiàn)方法 ， 就是選購的物品要一件一件地放進(jìn)購物車 ， 然后生成訂單 ， 繼而生成訂單進(jìn)行查詢和修改 ， 最后還要進(jìn)行訂單處理 。 實現(xiàn)購物車的 Bean 1．實現(xiàn)目標(biāo) 購物車所包含的數(shù)據(jù)是一個用戶的一次購買記錄 ， 因此在這一次購買中 ，我們考慮到用戶可能會選擇多種商品 ， 而每種商品又可能會選擇任意多個數(shù)目 ， 所以我們的購物車 Bean 應(yīng)該包含多個購物項 ， 而每個購物項又與一種商品相關(guān)聯(lián) 。 主要包括單個屬性：客戶購買的商品 、 購買數(shù)量以及總價錢 。 另外要說明的是 ， 我們設(shè)定 CartItem 屬性中的總價錢 ， 主要是為了迎合 22 商品因某種活動而出現(xiàn)的單價可能會變化 ， 例如在不同的階段 ， 我們的商店可能會采取不用的促銷策略 ， 給消費者不同的折扣 ； 另外 ， 還可能建立不同的會員制度 ， 不用級別的會員購買同一種商品的價格是有所不一樣的 ， 所以在里我要記錄每種商品的總價錢 。 我覺得在購物車中增加與刪除商品的操作方法是相對簡單的 ， 但就是要特別注意計算總價錢時要小心 。 其中 ， 購物項信息記錄了所有添加到購物車中的購物項的信息 ， 也就是記錄了一次購買的所有商品的種類和數(shù)量以及每種商品的總價錢 。 在 Cart 對象中 ， 還包括了 一系列購物車對象的操作方法 ， 分別包括為以下一些方法： addCartitem() 向購物車中增加一個購物項 ， 也就是增加客戶放入購物車中某種商品的記錄 。 updateCartitem() 這個方法用于修改購物車中某個商品的數(shù)量 ， 它采取的辦法是先將購物車中該商品的訂購記錄刪除 。 之所以這樣做是因為購物車中的訂購記錄都是記錄在內(nèi)存中的 ， 而如果需要對數(shù)據(jù)庫進(jìn)行操作則最好不要這樣 ， 在記錄 上進(jìn)行修改將會得到更高的效率 。 實現(xiàn)購物車的界面 購物車頁面主要是用于顯示用戶所選擇的商品信息以及每種商品的數(shù)量 ， 單價 ， 最后還要包括所選擇商品的總價錢 ， 如圖 51 所示： 23 圖 51 實現(xiàn)購物車界面 這個頁面需要后臺數(shù)據(jù)庫提供的參數(shù)是 cart， 也就是當(dāng)前用戶購物車對象 。 其中購物清單列出了購物車中所有商品的情況 ， 包括每種商品的單價 ，數(shù)量和總價錢 。 對購物車的操作按鈕主要就是 “ 結(jié)帳 ” 。 主要是因為在結(jié)帳的時候需要確定訂貨人是誰 ， 所以需要用戶登錄后才能去結(jié)帳 。 其中包括 ， 向購物車增加商品 ， 刪除商品和修改購物車中商品數(shù)量 。 圖 52 購物商品 單擊 “ 繼續(xù) 采購 ” 按鈕 ， 可以返回商品展示頁面 ， 供用戶繼續(xù)瀏覽并添加商品 ， 添加多個商品后的頁面這時重點看的是金額是否正確 。 在 “ 數(shù)量 ” 中可修改商品的數(shù)量 ， 每次修改完后 ， 都要單擊相應(yīng)的 “ 修改 ” 按鈕 ， 同時合計金額要根據(jù)商品數(shù)量的變化隨之發(fā)生變化 。 用戶的訂單信 息需要保存到在兩個表中： orders 表和 vends 表 。 vends 表用來保存訂單中包括的商品信息 ， 例如：購買的商品 ， 商品價格以及數(shù)量等 。 首先來實現(xiàn) orders 表所對應(yīng)的 ActionForm， 在這個類的開始首先定義了訂單狀態(tài)的常量 ， 這樣可以避免程序中使用不能確定含義的整數(shù)處理訂單狀態(tài)的情況出現(xiàn) ， 增強了程序的可讀性 。 其目的是為了在頁面上可以直接使用得到的商品對象來顯示商品的名稱 。 下面是介紹這些方法的功能： unspecified() 這是默認(rèn)的顯示 ， 是用戶單擊購物車頁面中 “結(jié)帳 “按鈕的響應(yīng)涵數(shù) 。 store() 這個方法用于響應(yīng)用戶提交的訂單的請求 。 25 list() 這個方法用于響應(yīng)用戶查看訂單列表的（包括正在處理的訂單列表和所有訂單列表）請求 ， 根據(jù)訂單的狀態(tài)得到訂單信息的列表 ， 在這個方法中要注意對權(quán)限的特殊處理 。 在這里對權(quán) 限設(shè)置需要單獨進(jìn)行處理 ， 訂單的權(quán)限規(guī)則主要包括以下兩點： 管理員可以查看所有的訂單信息 。 為了滿足這兩個要求 ， 在這里分別使用了兩個不同的 getOrders()方法來得到用戶可以訪問的訂單信息 ， 這兩個訂單的實現(xiàn)方法中 ， 當(dāng) user 為 0 的時候 ， 限制 userid 的條件就不會存在 ， 這樣就實現(xiàn)了在所有的記錄中進(jìn)行查詢的功能 。 （ 1） 訂單提交頁面 訂單提交頁面 主要是供確認(rèn)所選購的商品的種類 ， 數(shù)量和價格 。 圖 53 訂單提交頁面 26 在這個頁面中 ， 包括兩部分內(nèi)容 。后一部分用于用戶填寫送貨信息 ， 包括收件人的姓名 ， 地址 ， 聯(lián)系電話等信息 。 在這個頁面中是通過()從 Session中得到用戶基本信息 。 圖 54 訂單提交頁面 這個頁面需要后臺處理的數(shù)據(jù)是剛才所生成的訂單對象 ， 而這個頁面中的具體訂單條目的信息仍然取自購物車 ， 這樣避免了需要查詢數(shù)據(jù)庫的麻煩 。 27 圖 55 訂單列表頁面 這個頁面的實現(xiàn)比較簡單 ， 只是將后臺 Action查詢出來的訂單信息一一顯示出來 ， 并提供詳細(xì)的信息鏈接 ， 供用戶查看每個訂單的詳細(xì)信息 。 開 始用 戶 瀏 覽 商 品用 戶 登 陸發(fā) 送 訂 單訂 單 提 交成 功 ？訂 單 提 交 成 功結(jié) 束N oY e sN oY e s訂 單 是 否 提 交 ？ 圖 56 訂單過程流程圖 28 本 章 小結(jié) 在這一節(jié)中 ， 介紹了購物車模塊的實現(xiàn) 。 這里還介紹了訂單的一些查詢過程 ， 讓顧客很容易的看到自己購買的物品 。 29 第 6 章 系統(tǒng)測試 軟件測試概述 軟件危機曾經(jīng)是軟件界甚至整個計算機界最熱門的話題 。 現(xiàn)在人們已經(jīng)逐步認(rèn)識到所謂的軟件危機實際上僅是一種狀況 ， 那就是軟件中有錯誤 ， 正是這些錯誤導(dǎo)致了軟件開發(fā)在成本 、 進(jìn)度和質(zhì)量上的失控 。 問題在于如何去避