汽車銷售管理信息系統(tǒng)的系統(tǒng)規(guī)劃

1、汽車銷售管理信息系統(tǒng)的系統(tǒng)規(guī)劃一、汽車銷售管理信息系統(tǒng)的系統(tǒng)規(guī)劃第一節(jié) 項目開發(fā)背景隨著經(jīng)濟的發(fā)展和中國汽車市場的不斷擴大，某汽車配件公司也隨著發(fā)展的浪潮不斷擴大規(guī)模，隨之，訂單成倍增加，各項業(yè)務更加細化，各部門工作量增加，以往的人工處理方式就顯得力不從心，勞動強度大而且容易出錯。 項目開發(fā)目的 本課程設計的具體任務就是設計一個企業(yè)內(nèi)部業(yè)務管理信息系統(tǒng)，利用現(xiàn)代計算機和數(shù)據(jù)庫開發(fā)技術來代替人工處理，從而減輕企業(yè)各部門工作人員的勞動強度，提高工作質(zhì)量和效率，提高信息資源的利用率和企業(yè)管理水平。 可行性分析 現(xiàn)在企業(yè)的業(yè)務流程管理方式為手工處理，重復勞動多，勞動強度大，而且容易出錯，新系統(tǒng)的使用將

2、有以下幾個方面的優(yōu)勢：從技術上考察A 處理速度快，準確；B 通過權限的設置，數(shù)據(jù)的安全性好；C 方便查詢；D 控制精度或生產(chǎn)能力的提高2 從經(jīng)濟上考察A 系統(tǒng)建設不需要很大的投入；B 可縮減人員編制，減少人力費用；C 人員利用率的改進；3 從各種社會因素來考察A 可降低工作人員工作強度，提高效率，會得到企業(yè)上下員工的一致同意的；B 可引進先進的管理系統(tǒng)開發(fā)方案，從而達到充分利用企業(yè)現(xiàn)有資源綜上所述，本系統(tǒng)的開發(fā)立項是可行的。第二章 企業(yè)內(nèi)部業(yè)務管理信息系統(tǒng)的系統(tǒng)分析第一節(jié) 組織結構與功能分析 圖1 組織結構圖第二節(jié) 組織/業(yè)務關系圖業(yè)務聯(lián)系 組織程度銷售部會計部采購部倉庫經(jīng)理銷售活動*財務管理

3、*采購活動*庫存管理*行政監(jiān)督管理* 圖2 組織/業(yè)務關系圖第三節(jié) 業(yè)務功能一覽表經(jīng)營主管銷售主管倉庫主管采購主管財務主管業(yè)務員倉庫采購員財務會計銷售員管理應收款明細賬管理應付款賬目管理會計總賬編制報表收款發(fā)出訂貨單驗收貨物入庫接收發(fā)貨單修改庫存量管理貨物入庫出庫檢索庫存驗證訂貨單修改訂貨單開發(fā)貨單檢查暫存訂貨單確定顧客訂貨 圖3 業(yè)務功能一覽表 第四節(jié) 業(yè)務流程圖銷售歷史公司檔案存檔會計人員暫定訂單核對驗收入庫檢查暫存訂貨單應收款明細賬核對應收款明細賬采購人員供應商經(jīng)理訂貨配件匯總訂貨單填寫發(fā)貨單發(fā)貨單修改會計總賬會計總賬應付款賬目接受并開收據(jù)修改應收款明細賬編制報表查詢庫存量顧客銷售部門訂

4、貨單庫存配件發(fā)貨單驗證訂貨單確定顧客訂貨檢索庫存開發(fā)貨單并修改庫存產(chǎn)生暫定訂單登錄新客戶數(shù)據(jù)客戶數(shù)據(jù)到貨通知修改庫存量付款業(yè)務員收據(jù) 圖4 業(yè)務流程圖 第五節(jié) 數(shù)據(jù)流程圖登錄新顧客數(shù)據(jù)采購人員業(yè)務人員驗證訂貨單產(chǎn)生暫定訂單確定顧客訂貨開發(fā)貨單修改庫存暫定訂單應收款明細賬庫存配件顧客數(shù)據(jù)銷售歷史顧客糾正錯誤不合格訂單發(fā)訂單合格訂單不滿足訂貨 檢索滿足訂貨有新顧客 修改 開發(fā)貨單通知記錄記錄圖5-1 銷售過程數(shù)據(jù)流圖供貨商銷售部門采購人員訂貨配件匯總訂貨單訂貨填寫發(fā)貨單發(fā)貨單核對驗收入庫辦理銷售業(yè)務發(fā)貨單到貨通知庫存配件應收款明細賬通知銷售部門顧客確定給采購人員發(fā)貨單發(fā)出到貨 通知記錄對照暫存訂單

5、記錄產(chǎn)生 開出發(fā)貨圖5-2 采購過程數(shù)據(jù)流圖應付款賬目修改會計總賬付款顧客核對應收款明細賬接受并開收據(jù)收據(jù)修改應收款明細賬應收款明細賬會計人員供應商核對應付款賬目付款并修改應付款賬目會計總賬編制報表會計報表銷售分析報表庫存報表經(jīng)理庫存配件查詢庫存量給顧客收據(jù)開出現(xiàn)金支票轉賬無誤給會計發(fā)貨單無誤 修改 提供依據(jù) 提供依據(jù)提交編制提交編制提交編制圖5-3 財務過程數(shù)據(jù)流圖 銷售顧客配件采購部門供銷商經(jīng)理銷售部門庫存配件會計部門應付款賬目應收款明細賬報表客戶訂單公司合作合作編輯接受屬于查詢記錄屬于管理參考對應產(chǎn)生對應管理產(chǎn)生屬于購買供應第六節(jié) 系統(tǒng)數(shù)據(jù)庫建模-E-R模型分析1N1N1N111111N

6、11111NN1NNN11NN1 NNMMNN11N圖6-1 E-R圖圖6-2 E-R圖第七節(jié) 系統(tǒng)U/C矩陣分析功能數(shù)據(jù)類 顧客數(shù)據(jù)發(fā)貨單應收款賬目銷售歷史暫存訂單公司訂單到貨通知應付款賬目收付單據(jù)會計總賬報表庫存銷售管理客戶管理CU銷售配件UCUUU記錄業(yè)務CC采購管理記錄缺貨UCU追加訂貨UC驗貨入庫UUCCU財務管理收付款UUUUC會計核算UUUCU編制報表UUUUUCU庫存管理庫存管理UUUC監(jiān)督管理UUUUU 圖7 U/C矩陣第三章 汽車銷售管理信息系統(tǒng)的系統(tǒng)設計第一節(jié) 功能子系統(tǒng)劃分根據(jù)U/C矩陣分析，對汽車配件公司業(yè)務管理信息系統(tǒng)進行功能子系統(tǒng)劃分， 如圖8所示。本系統(tǒng)只要花分

7、為四個功能子系統(tǒng)：企業(yè)業(yè)務管理系統(tǒng)庫存管理財務管理采購管理銷售管理會計賬目管理會計報表管理訂貨管理客戶管理采購配件管理供應商管理庫存量管理庫存查詢管理圖8 系統(tǒng)功能子系統(tǒng)圖銷售管理子系統(tǒng)：對客戶數(shù)據(jù)、訂貨處理等銷售業(yè)務進行管理；財務管理子系統(tǒng)：負責各種報表和賬目的管理工作； 采購管理子系統(tǒng)：管理供應商信息，進行采購、收貨、驗貨等采購業(yè)務；庫存管理子系統(tǒng)：對倉庫存貨進行管理和監(jiān)督。第二節(jié) 層次化模塊結構圖汽車配件公司業(yè)務管理信息系統(tǒng)中，模塊劃分和處理過程設計是非常關鍵的一步，因此，我本著對系統(tǒng)可修改性、易讀性、易查錯性等方面進行設計。基本思想是：1、模塊化；2、圖表文字解說。其中，HIPO圖是一

8、種強有力的描述系統(tǒng)機構和模塊內(nèi)部處理功能的工具，它主要包括層次結構圖和IPO圖兩個部分。層次結構圖描述了整個系統(tǒng)的設計結構以及各類模塊之間的關系；IPO圖則描述了在某個特定模塊內(nèi)部的輸入（I）、處理過程（P）、輸出（O）思想。企業(yè)業(yè)務管理系統(tǒng)庫存管理財務管理采購管理銷售管理會計賬目管理會計報表管理訂貨管理客戶管理采購配件管理供應商管理庫存量管理庫存查詢管理 圖9-1 層次化結構模塊圖層次化結構模塊圖是從結構化設計的角度提出的一種工具。汽車配件公司業(yè)務管理信息系統(tǒng)的模塊化分為若干子系統(tǒng)，如銷售管理子系統(tǒng)、采購管理子系統(tǒng)等，它們之間是平級關系，并且，相互之間也不交叉。同時，一個模塊還下分了子模塊，

9、如銷售管理子系統(tǒng)下面包含了客戶管理和訂貨管理兩個子模塊。這樣，從整體上來劃分，形成從全局來進行管理的格局。訂貨管理訂單輸入訂單處理開發(fā)貨單圖9-2 層次化訂貨管理模塊結構圖輸入部分 I處理描述 P輸出部分 O1. 利用權限打開數(shù)據(jù)庫2. 輸入定貨單的顧客信息：名 稱、地址、電話、開戶行、賬號3. 輸入定貨單的各類信息：配 件名稱、規(guī)格、編號1. 核對用戶賬號和新建用賬號2. 核查定單信息3. 處理過程出錯信息 定單不合格新建用戶合格定單處理老用戶合格定單處理1. 將合格標志送回上一級調(diào)用模式2. 將核對的記錄記入文件3. 修改顧客記錄4. 將合格的定單信息以標準格式輸出模塊名稱：定單輸入系統(tǒng)使

10、用單位：銷售部圖10-1 訂單輸入IPO圖 訂單輸入IPO圖表示了訂單輸入模塊，講述了如何輸入客戶訂單，檢查其正確性，核對建立新的賬號等功能。模塊名稱：定單處理系統(tǒng)使用單位：銷售部和采購部輸入部分 I處理描述 P輸出部分 O1. 利用權限打開數(shù)據(jù)庫2. 上組模塊送入的合格的定單信息3. 輸入當前各配件庫存量1. 將定單的配件信息與配件當前 存量核對2. 處理過程出錯信息庫存量滿足定單要求處理庫存量暫缺處理零庫存量定單處理部分滿足庫存量處理1. 將合格標志送回上一級調(diào)用模式2. 將核對的記錄記入文件3. 完全滿足定單要求輸出發(fā)貨單4. 暫缺配件庫存量的暫存定貨單文件圖10-2 訂單處理IPO圖訂

11、單處理IPO圖表示了訂單處理模塊，講述了如何核對處理訂單，對庫存量和訂單進行比較處理等功能。模塊名稱：庫存量查詢系統(tǒng)使用單位：銷售部和經(jīng)理輸入部分 I處理描述 P輸出部分 O1. 利用權限打開數(shù)據(jù)庫2. 輸入查詢的配件編號、規(guī)格、名稱等信息3. 讀取近期銷售記錄4. 讀取原有配件庫存量1. 核對配件信息和原有配件庫存量2. 核查近期銷售記錄情況 3. 處理過程出錯信息當前零庫存量配件處理當前庫存量詳細處理1. 將合格標志送回上一級調(diào)用模式2. 將核對的記錄記入文件3. 輸出銷售庫存的當前查詢結果文件圖10-3 庫存查詢IPO圖庫存查詢IPO圖表示了庫存查詢管理模塊，講述了如何核對配件信息和原有

12、配件庫存量，核查近期銷售記錄情況以及對出錯信息的處理。暫存訂單輸入配件采購管理暫存訂單處理配件入庫圖9-3 層次化配件采購管理模塊結構圖模塊名稱：暫存訂單處理系統(tǒng)使用單位：采購部輸入部分 I處理描述 P輸出部分 O1. 利用權限打開數(shù)據(jù)庫2. 輸入暫存訂貨單配件信息： 編號、規(guī)格、名稱、暫缺數(shù)量等3. 讀取供應商列表信息1. 核查暫存訂貨單配件匯總信息2. 核對暫存配件和相應的供應商列表3. 處理過程1. 將合格標志送回上一級調(diào)用模式2. 將核對的記錄記入文件3. 修改供應商列表信息4. 輸出以供應商分類的采購訂貨單出錯信息按配件匯總處理按供應商匯總處理圖10-4 暫存訂單處理IPO圖暫存訂單

13、處理IPO圖表示了暫存訂單管理模塊，講述了如何核查暫存訂單配件匯總信息，核對暫存配件和相應的供應商的列表等處理過程。模塊名稱：配件入庫處理系統(tǒng)使用單位：采購部輸入部分 I處理描述 P輸出部分 O1. 利用權限打開數(shù)據(jù)庫2. 上組中輸出的采購訂貨單信息3. 輸入供應商發(fā)貨信息4. 讀取原庫存量信息5. 讀取標準配件質(zhì)量信息1. 核對采購訂貨單和發(fā)貨單信息2. 核對發(fā)貨配件質(zhì)量信息和標準配件 質(zhì)量信息3. 處理過程出錯信息核對出錯質(zhì)量不合格不合格配件處理合格配件入庫處理1. 將合格標志送回上一級調(diào)用模式2. 將核對記錄記入文件3. 修改庫存量信息4. 修改應付款明細帳圖10-5 配件入庫處理IPO

14、圖配件入庫處理IPO圖表示了配件管理模塊，講述了如何核對采購訂貨單合法貨單信息，核對發(fā)貨配件質(zhì)量信息和標準配件質(zhì)量信息等功能。第五章 系統(tǒng)設計總結第一節(jié) 項目實施中各個工作流程及時間分布1 項目開發(fā)的編寫 1天2 業(yè)務流程圖設計 2天3 數(shù)據(jù)流程圖設計 1天4 E-R圖設計 1天5 U/C矩陣設計 2天6 HIPO圖設計 2天7 文檔修改、定稿 1天第二節(jié) 本人系統(tǒng)設計特點1 優(yōu)點：本系統(tǒng)具有較強的直觀性，設計完整，能較好的體現(xiàn)系統(tǒng)的設計構思；缺點：設計的有些方面有點簡單，有很多地方還需進一步分析改進。 目 錄前言1第一部分 項目管理與計劃1實驗1 制定項目計劃1實驗2 項目可行性分析1第二部

15、分 系統(tǒng)分析1實驗3 項目需求收集1實驗4 用例建模1實驗5 通過用例獲取概念數(shù)據(jù)模型1實驗6 將概念數(shù)據(jù)模型轉換為對象關系模型1實驗7 分析類圖建模（序列圖、交互圖、狀態(tài)圖、活動圖）1實驗8 確定設計方案（*）1第三部分 系統(tǒng)設計1實驗9 物理數(shù)據(jù)庫設計1實驗10 確定系統(tǒng)構架等設計元素、設計類圖建模1實驗11 界面設計1第四部分 系統(tǒng)實現(xiàn)1實驗12 系統(tǒng)實現(xiàn)代碼（*）1附錄：項目成員分工情況1備注：*為選做實驗。第一部分實驗一：制定項目計劃實驗二：制定項目計劃從經(jīng)濟上分析項目的可行性一、 投資成本印第安漢堡餐品預定系統(tǒng)在投資成本上包括兩方面，一次性成本和續(xù)生成本。一次性成本包括基建投資和其

16、他一次性投資，具體是指與項目活動、系統(tǒng)開發(fā)和系統(tǒng)啟用有關的費用，包括在該信息系統(tǒng)開發(fā)過程中全部一次性投入，如系統(tǒng)開發(fā)、新硬件和軟件的采購，用戶培訓、站點準備、數(shù)據(jù)或系統(tǒng)轉化。根據(jù)搜集到的資料顯示，印第安漢堡的餐品預定系統(tǒng)的一次性成本如下所示：（1） PC機：2臺，5000*2=10000元（2） Microsoft SQL Server 2005（1套）：5000元（3） Microsoft Server2008（1套）：10000元（4） 打印機1臺：1000元（5） 人員培訓：7人/2000元，合計14000元總計：本系統(tǒng)開發(fā)的一次性投入為40000元，并且新系統(tǒng)需在6個月內(nèi)實現(xiàn)。經(jīng)常性支

17、出是指由于正在進行的系統(tǒng)演化和使用而產(chǎn)生的費用，例如應用軟件維護、逐漸增加的數(shù)據(jù)存儲費用、增加的溝通、新軟件和硬件租借以及消費用品和其他支出等。根據(jù)搜集到的資料顯示，在印第安漢堡的餐品預定系統(tǒng)中，這種經(jīng)常性投入表現(xiàn)為續(xù)生成本，并且需要連續(xù)投資5年，具體如下所示：（1） 預定系統(tǒng)的維護：1000元/年*5年=5000元（2） 每年增加的數(shù)據(jù)存儲費用：5000元/年*5年=25000元（3） 消費用品支出：800元/年*5年=4000元（4） 其他支出：1000元/年*5年=5000元綜上可得，印第安漢堡的餐品預定系統(tǒng)為15000美元/年，折算為現(xiàn)值為96862元。具體如下圖所示。（貼現(xiàn)率為10%

18、時）二、 投資收益由于我們的系統(tǒng)結構較為簡單，功能單一，初期投入后利潤也不會有太多。我們同樣將系統(tǒng)運行后的投資收益分為一次性收益和經(jīng)常性收益。根據(jù)預測，印第安漢堡的餐品預定系統(tǒng)的投資收益如下所示：1 一次性收益：無。2 經(jīng)常性收益：（1）由于系統(tǒng)的改進而增加的收益：2000元/年*5=10000元（2）市場占有率的提高而增加的收益（假設市場占有率以每年10%增加）1000+1000*（1+10%）1+1000*（1+10%）2+1000*（1+10%）3+1000*（1+10%）4+1000*（1+10%）5=7716元（3）效率的提高：1000元/年*5=5000元（4）不可定量的其他收益：

19、5年共2284元開發(fā)該訂餐系統(tǒng)，當其投入運行后，每年的凈收益為25000元，再考慮貨幣的時間價值，系統(tǒng)每年的凈收益如下所示。（貼現(xiàn)率為10%時）綜上可知，五年內(nèi)系統(tǒng)的總收益為94770美元。三、 成本/收益分析通過上述成本收益的分析可知，當貼現(xiàn)率為10%時，新開發(fā)的信息系統(tǒng)總成本為96862元，總收益為94770元。由于總成本是大于總收益的，所以系統(tǒng)越運行，越虧損，該信息系統(tǒng)不具備經(jīng)濟上的可行性。我們調(diào)整貼現(xiàn)率可知，當貼現(xiàn)率為5%時，系統(tǒng)具有經(jīng)濟上的可行性。（貼現(xiàn)率為5%）總成本為104942美元。總收益為108237美元。（貼現(xiàn)率為5%）成本收益分析（1） 投資回收期為第4.58年。（2）

20、投資回報率為3.14%（3） 凈收益108237美元-104942美元=3295美元。從經(jīng)濟上考慮，當貼現(xiàn)率為5%是，新系統(tǒng)在經(jīng)濟上具有可行性。第二部分實驗三：項目需求收集我們選擇訪談的形式進行需求收集，分別對顧客、服務員、廚師進行提問，以下是我們設計的問題針對顧客：1 您更偏重哪種口味的漢堡 飲料 冰淇淋2 能說一下漢堡 飲料 冰淇淋與季節(jié)的關系嗎3 您希望多長時間拿到您的定餐4 您一般什么時候來店里消費5 您希望我們店通過什么方法實現(xiàn)個性化推薦，發(fā)傳單 貼海報 咨詢服務員針對服務員：1 一天中什么時候是消費的最高峰2 你覺得什么樣的界面操作比較方面3 你覺得系統(tǒng)存在什么樣的問題4 您對系統(tǒng)

21、有什么樣的改進意見5 您覺得訂餐系統(tǒng)對企業(yè)帶了的效益體現(xiàn)在哪里針對廚師：1 您希望多長時間來準備漢堡 飲料 冰淇淋2 現(xiàn)在一天大約做多少漢堡 飲料 冰淇淋 （庫存的要求）3 對這個系統(tǒng)您最不喜歡的是什么4 您對訂餐系統(tǒng)在缺貨處理上有怎樣的評價5 您覺得訂餐系統(tǒng)對你的工作有何幫助最可能得到的文檔是訪談記錄，最不可能得到的文檔是觀察筆記實驗四：用例建模我們?yōu)橛〉诎矟h堡構建的信息系統(tǒng)主要是為了方便客戶點餐以及管理員及時進行庫存控制，以減少顧客在點餐和取餐時的時間開銷，為印第安漢堡贏取更大的利益。一、印第安漢堡點餐系統(tǒng)的用例圖如下所示。二、印第安漢堡點餐系統(tǒng)的用例描述1.顧客通過印第安漢堡的點餐系統(tǒng)生

22、成訂單的用例描述用例名稱：生成訂單簡要說明：電話訂餐接線員或者前臺接到顧客的訂單，生成訂單一式三聯(lián)。參與者：電話訂餐接線員或者前臺前置條件：顧客的訂餐需求是有效的后置條件：生成正確的訂單，包括顧客的姓名、電話、住址以及訂單編號 等基礎內(nèi)容。假設條件：電話訂餐接線員或者前臺已經(jīng)成功登錄訂餐系統(tǒng)基本操作流程：（1）接線員或者前臺接收到顧客的有效訂餐（2）在訂餐系統(tǒng)中輸入顧客需求的餐品名稱進行查詢，比對顧客對餐品的需求量和庫存量。（3）在庫存充足的條件下，點擊進入目標餐品的預訂頁面，要求顧客報送姓名、電話及住址信息，點擊“確認按鈕”生成訂單，此項操作只針對電話訂餐接線員，如為前臺訂餐，直接在庫存充足

23、的情況下，點擊“確定”按鈕生成訂單一式三聯(lián)即可。（4）系統(tǒng)將顧客的訂單信息寫入數(shù)據(jù)庫，以進行庫存管理。可選操作流程：（1）顧客有信息輸入錯誤的，前臺人員不予以確認原錯誤訂單，再按照顧客的正確信息重新生成訂單即可。（2）顧客在訂餐過程中臨時決定退訂的，操作如“顧客信息輸入有誤”同樣處理。2.管理員對數(shù)據(jù)庫中的訂單進行管理的用例描述用例名稱：訂單管理簡要說明：由后臺管理員對已經(jīng)生成的訂單進行查詢和刪除參與者：后臺管理員前置條件：點餐系統(tǒng)中存在業(yè)已生成的訂單后置條件：顯示訂單信息、刪除相應的訂單假設條件：后臺管理員使用特殊賬號正確登錄到點餐系統(tǒng)基本操作流程：(1) 后臺管理員輸入需要查詢的訂單編號，

24、也可以通過顧客名稱、電話號碼等進行訂單查詢。(2) 當后臺管理員接到顧客的退訂申請時，查詢到相應的訂單，進行刪除操作，并及時通知其他有關部門。(3) 后臺管理員實時查詢庫存量，向有關部門報告，進行有效的庫存控制?？蛇x操作流程：對于餐品已經(jīng)送出后接到顧客退訂申請的，及時刪除相應的訂單。3.后臺管理員對餐品進行管理用例描述用例名稱：餐品管理簡要說明：后臺管理員根據(jù)公司業(yè)務發(fā)展的需要對點餐系統(tǒng)中供應的餐品進行增、刪、該操作。參與者：后臺管理員前置條件：點餐系統(tǒng)中確實存在需要修改的餐品信息后置條件：顯示更新后的餐品信息假設條件：后臺管理員使用特殊賬號正確登錄到點餐系統(tǒng)基本操作流程：(1) 后臺管理員在

25、主頁面上點擊“增加餐品”按鈕，進入增加餐品的二級頁面，填寫相應信息，完成餐品增加操作。(2) 后臺管理員在主頁上輸出查詢條件，選擇出需要修改的餐品（一般是餐品價格的修改），點擊餐品圖片進入二級頁面， 完 成對餐品的修改操作。(3) 后臺管理員在主頁上輸出查詢條件，選擇出需要刪除的餐品，點擊餐品圖片右下方的“刪除，”完成對餐品的刪除操作?？蛇x操作流程：增加餐品的前提是庫存不為零，庫存超過一定數(shù)量的餐品系統(tǒng)顯示不能刪除餐品信息。4.印第安漢堡點餐系統(tǒng)對庫存量進行管理的用例描述用例名稱：庫存控制簡要說明：系統(tǒng)根據(jù)訂單的數(shù)量和內(nèi)容減少相應的庫存量。參與者：后臺管理員前置條件：系統(tǒng)中存在一些已經(jīng)生成的訂

26、單后置條件：庫存量作相應的變動假設條件：后臺管理員使用特殊賬號正確登錄到點餐系統(tǒng)基本操作流程：(1) 系統(tǒng)根據(jù)已經(jīng)確認的訂單中餐品名稱和餐品數(shù)量做相應庫存量的減少。每銷售出去一個餐品，庫存數(shù)據(jù)庫中對應餐品的庫存量相應的減一。(2) 系統(tǒng)顯示每種餐品剩余庫存量以便管理員及時同有關部門協(xié)調(diào)，增加相應餐品的供給?？蛇x操作流程：庫存量為零時，系統(tǒng)提示不能進行相應的庫存減少的操作。5送貨員向顧客供應訂貨的用例描述用例名稱：供應訂貨簡要說明：送貨員憑借其中一份訂單與顧客錢貨兩清，完成整個訂餐過程參與者： 送貨員前置條件：顧客完成“點餐”用例，且餐品未送達。后置條件：交易完成，刪除相應訂單假設條件：顧客提交

27、了有效的點餐需求基本操作流程： (1) 送貨員憑借訂單與顧客完成交易后，向有關管理部門提示“送貨成功”。(2) 系統(tǒng)根據(jù)訂單中的餐品名稱和餐品數(shù)量作相應庫存量的減少?？蛇x操作流程：如果交易不成功的話，送貨員應及時提醒后臺管理員，后臺管理員應及時刪除相應訂單。實驗五：通過用例獲取概念數(shù)據(jù)模型概念數(shù)據(jù)模型是對組織數(shù)據(jù)的描繪，它以一種獨立于現(xiàn)實的方式說明了數(shù)據(jù)的結構和數(shù)據(jù)之間的相互關系。本次實驗通過對前面用例進行分析，并結合我們訂餐系統(tǒng)的功能和需求，建立概念數(shù)據(jù)模型，具體步驟如下：1、標識用例中的類通過觀察用例并結合實際分析，我們可以抽象出以下幾個類：Admin（管理員），Order（訂單），Cus

28、tomer（顧客），Product（產(chǎn)品），以及關聯(lián)類Lineitem（訂單行項目）。2、確定每一個類的屬性 用例中沒有提供關于屬性的所有詳細資料，因此我查看了與“訂單”用例相關文檔，并結合本系統(tǒng)的功能需求，將屬性分配到類。Admin（管理員）：AdminId（管理員號），AdminName（管理員姓名），AdminPsd（管理員密碼），AdminType（管理員類型）Order（訂單）：OrderId（訂單號），OrderDate（訂單時間），SubTotal（小計），TotalAmount（總數(shù)量），Customer（顧客）：CustId（顧客號），CustomerName（顧客姓名），C

29、ustPhone（顧客電話）CustAddress（顧客地址）Product（產(chǎn)品）：ProId（產(chǎn)品號），ProName（產(chǎn)品名稱）， ProPrice（產(chǎn)品單價），ProPicture（產(chǎn)品圖片），ProAbstract（產(chǎn)品介紹），ProAmount（產(chǎn)品庫存）LineItem（訂單行項目）：Quantity（數(shù)量），ActualPrice（實際價格），LineAmount（項目總數(shù)量）3、確定標識符即選擇一個屬性作為這個類的唯一標識符。在此我們選擇AdminId（管理員號）、OrderId（訂單號、CustId（顧客號）、ProId（產(chǎn)品號）為標識符4、考慮屬性的性質(zhì)在此，除了普通的屬

30、性以外，我們認為顧客聯(lián)系方式應除了常用的一個以外，至少一個備用，所以CustPhone（顧客電話）為多值屬性，訂單的ubTotal（小計），TotalAmount（總數(shù)量），產(chǎn)品的ProAmount（產(chǎn)品庫存）可由其他數(shù)據(jù)確定，應為導出屬性。5、屬性與屬性之間的關系通過分析我們可以知道，一個顧客可以下多個訂單，一個訂單只能對應一個顧客購買；一個管理員（前臺）可以處理多個訂單，但每個訂單對應一個管理員，因此Customer和Order，Asmin和Order的關系是一對一的。每個訂單可包含多種產(chǎn)品，每個產(chǎn)品可以包括在不同的訂單里，因此Product和Order為多對多的關系，用關聯(lián)類LineIt

31、em來表示。6、建立概念數(shù)據(jù)模型 綜上所述，我們建立的概念數(shù)據(jù)模型如下圖所示：實驗六：將概念數(shù)據(jù)模型轉換為對象關系模型對象關系數(shù)據(jù)模型是帶有面向對象擴充的關系數(shù)據(jù)模型，以關聯(lián)表或關系的形式描繪數(shù)據(jù)。本次實驗基于前面概念數(shù)據(jù)模型的建立，將其轉化為對象關系，接著將所有關系合并為最終的、綜合的一組關系，其步驟如下：1、將類轉化為對象關系類的標識符成為該對象關系的主鍵，類的其他屬性成為該對象關系的非主鍵屬性。則對象關系如下：Admin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，OrderDate，SubTotal，TotalAmount）Cu

32、stomer（CustId，CustomerName，CustPhone，CustAddress）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，ProAmount）2、為1：n關系安排外鍵在此系統(tǒng)中，有兩個一對多的關系，根據(jù)將1方的主鍵增加為n方的外鍵，則order關系將被修改為包含CustId 和AdminId，作為外鍵。Order（OrderId，CustId，AdminId，OrderDate，SubTotal，TotalAmount）3、最后轉化關聯(lián)類 在Order和Product之間有一關聯(lián)類LineItem，其可映像為

33、對象關系，并用兩個類的主鍵OrderId 和ProId的組合作為他的主鍵。LineItem（OrderId ，ProId ，Quantity，ActualPrice，LineAmount）4、規(guī)范化關系對象，進一步細化由于Customer允許通過接收多值屬性違背了第一范式，因而Customer不是一個良構關系，而是一個對象關系，又因為我們進一步討論決定接收純粹的關系模型，因此將Customer分為關系，為：Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，CustPhone）5、對象關系模型 經(jīng)過一步步的細化，我們產(chǎn)生了6個對

34、象類，導出的對象關系模型如下：Admin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，CustId，AdminId，OrderDate，SubTotal，TotalAmount）LineItem（OrderId ，ProId ，Quantity，ActualPrice，LineAmount）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，ProAmount）Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，C

35、ustPhone）實驗七：分析類圖建模這一部分通過圖對系統(tǒng)進行描述1.順序圖：交互圖是幫助在一個用例的分析類之間分配責任并說明類對象之間的相互交互的圖，常用的交互圖的類型是順序圖，它以時間順序的方式說明類的對象之間的交互。下圖為按照指導原則描繪的“預訂”用例的順序圖：圖中詳細描述了“預定”用例的順序圖：參與者：Customer選擇一個或多個產(chǎn)品調(diào)用該用例，這個消息/select item（選擇產(chǎn)品項）表明，它被傳給：OrderForm。表單將信息傳遞給控制對象：OrderControl，于是創(chuàng)建訂單?？刂茖ο髮?chuàng)建新訂單的責任傳給了：Order，：Order創(chuàng)建一個新訂單。類似的，控制將增加一

36、個項目的責任傳遞給了：LineItem。它來創(chuàng)建一個新的項目。或者，：Order對象可以負責增加：LineItem對象。2.活動圖： 活動圖和順序圖相似，但兩個圖的重點不同，順序圖在于說明一個程序中的控制流，而活動圖說明系統(tǒng)中活動到活動的控制流，什么活動可以并行進行，和任何通過流的可選路徑。 “預定”用例的活動圖： 子流程同步的活動圖： 3.狀態(tài)圖： 狀態(tài)圖通過制定一個對象在自己的生存期間響應時間而經(jīng)歷的狀態(tài)序列以及對這些事件的響應來描述對象的行為。一個對象的狀態(tài)是在對象生存期間的一個條件或情況，在這個時間它滿足某些條件，執(zhí)行某些活動或等待某些事件?？梢哉J為對象的活動圖是狀態(tài)圖的一個特例。 例

37、如， 對象訂單的狀態(tài)經(jīng)歷創(chuàng)建、供應、完成，它的狀態(tài)圖如下： 4.分析類圖： 分析類圖說明分析類和這些類之間的關系，有兩種關系結構關系和行為關系，結果方面從數(shù)據(jù)建模中可以獲得，分析類圖的行為方面可以從順序圖或通信圖導出。下圖是“預訂”用例的一個分析類圖：OrderOrderIdOrderDateSubTotalTotalAmount/create order()/get order info()/update order info()CustomerCustIdCustomerNameCustPhoneCustPhone/get customer info()/charge customer()

38、ProductProIdProNameProPrice/get products info()/update inventoryLineItemQuantityActualPriceLineAmount/add item()/get lineitems()/write order lineitems()BUYOrderControl/select item()/confirm order()/calc total()OrdertForm/select item()/confirm order()第三部分實驗八：物理數(shù)據(jù)庫設計 物理數(shù)據(jù)庫設計是對系統(tǒng)存儲結構和存取方法等依賴于具體計算機結構的各項

39、物理設計措施的設計，涉及訪問的效率考慮因素比如響應時間和事務吞吐量，本實驗旨在確保用戶在運行查詢時不必等待不合理的時間，從而有效執(zhí)行任務。1、關系對象屬性特性描述 在實驗六中，我們的到如下的對象關系Admin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，CustId，AdminId，OrderDate，SubTotal，TotalAmount）LineItem（OrderId ，ProId ，Quantity，ActualPrice，LineAmount）Product（ProId，ProName， ProPrice，ProPictur

40、e，ProAbstract，ProAmount）Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，CustPhone） 根據(jù)上述對象關系，結合邏輯數(shù)據(jù)模型以及實際情況，分析了各個屬性的特征，如數(shù)據(jù)類型、設計域、數(shù)據(jù)的完整性（默認值、是否為空、控制范圍、參照完整性）等，具體涉及如下表所示：Customer字段名數(shù)據(jù)類型是否允許為空鍵或索引說明CustIDInt（20）否主鍵唯一；系統(tǒng)自動賦予CustTomerNameNvarchar（30）否CustAddresNvarchar（30）否CustPhone字段名數(shù)據(jù)類型是否允許為

41、空鍵或索引說明CustIDInt（20）否主鍵參照顧客表CustPhoneNvarchar（30）否主鍵唯一Admin字段名數(shù)據(jù)類型是否允許為空鍵或索引說明AdminIDInt(20)否主鍵唯一；系統(tǒng)自動賦予AdminPsdInt(30)否唯一；長度大于6AdminNameNvarchar（30）否AdminTypeNuem否分為前臺管理員、電話預定員、系統(tǒng)管理員Order字段名數(shù)據(jù)類型是否允許為空鍵或索引說明OrderIDInt(20)否主鍵唯一；系統(tǒng)自動賦予CustIDInt（20）否參照顧客表AdminIDInt(20)否參照管理員表 OrderDatedatetime否系統(tǒng)自動生成Su

42、bTotalNumeric(18,2)否根據(jù)LineItem表生成TotalAmountInt是根據(jù)LineItem表生成LineItem字段名數(shù)據(jù)類型是否允許為空鍵或索引說明OrderIDInt(10)否主鍵參照訂單表ProIdInt(20)否主鍵參照產(chǎn)品表QuantityInt（10）否ActualPrice Numeric(18,2)否LineAmountNumeric(18,2)否系統(tǒng)自動生成Product 字段名數(shù)據(jù)類型是否允許為空鍵或索引說明ProIdInt(20)否主鍵唯一；系統(tǒng)自動賦予ProNameNvarchar(50)否唯一ProPrice Numeric(8,2)否Pro

43、PicturImage否唯一ProAbstractNtest否唯一；非空ProAmountNtest是參照留言表2、物理數(shù)據(jù)庫文件組織及索引設計根據(jù)實際情況和需求分析，我們估計了表的行的大小和數(shù)目如下圖所示。表名行對象數(shù)目每個行對象的字節(jié)數(shù)Admin2000200Order5000000100LineItem1000000040Product4000200Customer500000200CustPhone100000050我們假設選擇的塊大小是由4000個可用字節(jié)的4k（4096個字節(jié)）。在Admin表的例子中，分塊因子4000/200。Admin表的大小是2000/20。Admin表的掃描

44、時間是100*2.5ms為0.25s。類似的可以算出其余幾個表的計算如下圖表名行對象數(shù)目每行字節(jié)數(shù)分塊因子（BF）塊數(shù)掃描時間（秒）是否需要索引Admin200020020100否Order500000010040125000是LineItem1000000040100100000250是Product400020020200否Customer5000002002025000625是CustPhone1000000508012500是上面的計算表明1） 索引這六個表的6個主鍵AdminId、OrderId、（OrderId ，ProId）、ProId、CustId、（CustId，CustPh

45、one）。主鍵一般是最常被訪問的屬性。2） 可將Admin和Product存儲在數(shù)據(jù)庫服務器的高速緩沖去。即使沒有被緩存，掃描時間也只不過0.25s和5s，沒有必要索引除了主鍵之外的任何屬性。3）Order、LineItem、Customer和CustPhone是大表，并且需要索引來加快查詢的速度?？梢酝ㄟ^索引具有大量不同值的外鍵提高檢索速度。很明顯AdminId、OrderId、ProId、CustId都是很好的索引候選。4）索引被頻繁訪問并具有相對大量不同質(zhì)的非屬性鍵如CustomerName也可作為索引。數(shù)據(jù)九：確定系統(tǒng)構架等設計元素、設計類圖建模實驗十：界面設計印第安漢堡點餐系統(tǒng)是基于提高點餐周轉速率以及更好地進行庫存控制而開發(fā)的，在界面設計上我們也充分考慮到快餐店的經(jīng)營特點，盡可能地提供便捷的頁面操作方式，提高漢堡店的經(jīng)營效率。（1）通用原則 界面色彩要求：計算機屏幕的發(fā)光成像和普通視覺成像有很大的不同，應該注意這種差別作出恰當?shù)纳蚀钆?。例如輕松的淡彩為主配色，灰色系為主配色等等。我們的點餐系統(tǒng)采用橙黃的為基調(diào)，旨在提供一種溫馨、熱情的界面感覺。（2）界面平面版式要求：系統(tǒng)樣式排版整齊劃一，盡可能劃分不同的功能區(qū)域于固定位置