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

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

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

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

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

5、款明細(xì)賬1.1.5通知銷售部門顧客確定給采購人員發(fā)貨單發(fā)出到貨 通知記錄對照暫存訂單記錄產(chǎn)生 開出發(fā)貨圖5-2 采購過程數(shù)據(jù)流圖應(yīng)付款賬目應(yīng)付款賬目1.1.5修改會計總賬1.1.1付款顧客1.1.2核對應(yīng)收款明細(xì)賬1.1.3接受并開收據(jù)收據(jù)1.1.4修改應(yīng)收款明細(xì)賬應(yīng)收款明細(xì)賬會計人員供應(yīng)商1.1.6核對應(yīng)付款賬目1.1.7付款并修改應(yīng)付款賬目會計總賬1.1.8編制報表會計報表銷售分析報表庫存報表經(jīng)理庫存配件1.1.9查詢庫存量給顧客收據(jù)開出現(xiàn)金支票轉(zhuǎn)賬無誤給會計發(fā)貨單無誤 修改 提供依據(jù)提供依據(jù)提交編制提交編制提交編制圖5-3 財務(wù)過程數(shù)據(jù)流圖銷售顧客配件采購部門供銷商經(jīng)理銷售部門庫存配件會

6、計部門應(yīng)付款賬目應(yīng)收款明細(xì)賬報表客戶訂單公司合作合作編輯接受銷售顧客配件采購部門供銷商經(jīng)理銷售部門庫存配件會計部門應(yīng)付款賬目應(yīng)收款明細(xì)賬報表客戶訂單公司合作合作編輯接受屬于查詢記錄屬于管理參考對應(yīng)產(chǎn)生對應(yīng)管理產(chǎn)生屬于購買供應(yīng)1N1N1N111111N11111NN1NNN11NN1 NNMMNN11N圖6-1 E-R圖圖6-2 E-R圖第七節(jié) 系統(tǒng)U/C矩陣分析功能數(shù)據(jù)類功能數(shù)據(jù)類顧客數(shù)據(jù)發(fā)貨單應(yīng)收款賬目銷售歷史暫存訂單公司訂單到貨通知應(yīng)付款賬目收付單據(jù)會計總賬報表庫存銷售管理客戶管理CU銷售配件UCUUU記錄業(yè)務(wù)CC采購管理記錄缺貨UCU追加訂貨UC驗(yàn)貨入庫UUCCU財務(wù)管理收付款UUUUC

7、會計核算UUUCU編制報表UUUUUCU庫存管理庫存管理UUUC監(jiān)督管理UUUUU圖7 U/C矩陣汽車銷售管理信息系統(tǒng)的系統(tǒng)設(shè)計功能子系統(tǒng)劃分根據(jù)U/C矩陣分析，對汽車配件公司業(yè)務(wù)管理信息系統(tǒng)進(jìn)行功能子系統(tǒng)劃分， 如圖8所示。本系統(tǒng)只要花分為四個功能子系統(tǒng)：企業(yè)業(yè)務(wù)管理系統(tǒng)企業(yè)業(yè)務(wù)管理系統(tǒng)庫存管理財務(wù)管理采購管理銷售管理會計賬目管理會計報表管理訂貨管理客戶管理采購配件管理供應(yīng)商管理庫存量管理庫存查詢管理圖8 系統(tǒng)功能子系統(tǒng)圖銷售管理子系統(tǒng)：對客戶數(shù)據(jù)、訂貨處理等銷售業(yè)務(wù)進(jìn)行管理；財務(wù)管理子系統(tǒng)：負(fù)責(zé)各種報表和賬目的管理工作； 采購管理子系統(tǒng)：管理供應(yīng)商信息，進(jìn)行采購、收貨、驗(yàn)貨等采購業(yè)務(wù)；庫存

8、管理子系統(tǒng)：對倉庫存貨進(jìn)行管理和監(jiān)督。層次化模塊結(jié)構(gòu)圖汽車配件公司業(yè)務(wù)管理信息系統(tǒng)中，模塊劃分和處理過程設(shè)計是非常關(guān)鍵的一步，因此，我本著對系統(tǒng)可修改性、易讀性、易查錯性等方面進(jìn)行設(shè)計?；舅枷胧牵?、模塊化；2、圖表文字解說。其中，HIPO圖是一種強(qiáng)有力的描述系統(tǒng)機(jī)構(gòu)和模塊內(nèi)部處理功能的工具，它主要包括層次結(jié)構(gòu)圖和IPO圖兩個部分。層次結(jié)構(gòu)圖描述了整個系統(tǒng)的設(shè)計結(jié)構(gòu)以及各類模塊之間的關(guān)系；IPO圖則描述了在某個特定模塊內(nèi)部的輸入（I）、處理過程（P）、輸出（O）思想。企業(yè)業(yè)務(wù)管理系統(tǒng)企業(yè)業(yè)務(wù)管理系統(tǒng)庫存管理財務(wù)管理采購管理銷售管理會計賬目管理會計報表管理訂貨管理客戶管理采購配件管理供應(yīng)商管理

9、庫存量管理庫存查詢管理 圖9-1 層次化結(jié)構(gòu)模塊圖層次化結(jié)構(gòu)模塊圖是從結(jié)構(gòu)化設(shè)計的角度提出的一種工具。汽車配件公司業(yè)務(wù)管理信息系統(tǒng)的模塊化分為若干子系統(tǒng)，如銷售管理子系統(tǒng)、采購管理子系統(tǒng)等，它們之間是平級關(guān)系，并且，相互之間也不交叉。同時，一個模塊還下分了子模塊，如銷售管理子系統(tǒng)下面包含了客戶管理和訂貨管理兩個子模塊。這樣，從整體上來劃分，形成從全局來進(jìn)行管理的格局。訂貨管理訂貨管理A.1訂單輸入A.2.1訂單處理A.2.2開發(fā)貨單A.2.3圖9-2 層次化訂貨管理模塊結(jié)構(gòu)圖輸入部分輸入部分 I處理描述 P輸出部分 O1. 利用權(quán)限打開數(shù)據(jù)庫2. 輸入定貨單的顧客信息：名 稱、地址、電話、開戶

10、行、賬號3. 輸入定貨單的各類信息：配 件名稱、規(guī)格、編號核對用戶賬號和新建用賬號2. 核查定單信息3. 處理過程出錯信息 定單不合格新建用戶合格定單處理老用戶合格定單處理將合格標(biāo)志送回上一級調(diào)用模式2. 將核對的記錄記入文件3. 修改顧客記錄4. 將合格的定單信息以標(biāo)準(zhǔn)格式輸出模塊名稱：定單輸入系統(tǒng)使用單位：銷售部圖10-1 訂單輸入IPO圖 訂單輸入IPO圖表示了訂單輸入模塊，講述了如何輸入客戶訂單，檢查其正確性，核對建立新的賬號等功能。模塊名稱：定單處理系統(tǒng)模塊名稱：定單處理系統(tǒng)使用單位：銷售部和采購部輸入部分 I處理描述 P輸出部分 O1. 利用權(quán)限打開數(shù)據(jù)庫2. 上組模塊送入的合格的

11、定單信息3. 輸入當(dāng)前各配件庫存量1. 將定單的配件信息與配件當(dāng)前 存量核對2. 處理過程出錯信息庫存量滿足定單要求處理庫存量暫缺處理零庫存量定單處理部分滿足庫存量處理1. 將合格標(biāo)志送回上一級調(diào)用模式2. 將核對的記錄記入文件3. 完全滿足定單要求輸出發(fā)貨單4. 暫缺配件庫存量的暫存定貨單文件圖10-2 訂單處理IPO圖訂單處理IPO圖表示了訂單處理模塊，講述了如何核對處理訂單，對庫存量和訂單進(jìn)行比較處理等功能。模塊名稱：庫存量查詢系統(tǒng)模塊名稱：庫存量查詢系統(tǒng)使用單位：銷售部和經(jīng)理輸入部分 I處理描述 P輸出部分 O1. 利用權(quán)限打開數(shù)據(jù)庫2. 輸入查詢的配件編號、規(guī)格、名稱等信息3. 讀取

12、近期銷售記錄4. 讀取原有配件庫存量1. 核對配件信息和原有配件庫存量2. 核查近期銷售記錄情況 3. 處理過程出錯信息當(dāng)前零庫存量配件處理當(dāng)前庫存量詳細(xì)處理1. 將合格標(biāo)志送回上一級調(diào)用模式2. 將核對的記錄記入文件3. 輸出銷售庫存的當(dāng)前查詢結(jié)果文件圖10-3 庫存查詢IPO圖庫存查詢IPO圖表示了庫存查詢管理模塊，講述了如何核對配件信息和原有配件庫存量，核查近期銷售記錄情況以及對出錯信息的處理。暫存訂單輸入暫存訂單輸入C.2.1C.2配件采購管理C.2.2暫存訂單處理C.2.3配件入庫圖9-3 層次化配件采購管理模塊結(jié)構(gòu)圖模塊名稱：暫存訂單處理系統(tǒng)模塊名稱：暫存訂單處理系統(tǒng)使用單位：采購

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

14、：采購部輸入部分 I處理描述 P輸出部分 O1. 利用權(quán)限打開數(shù)據(jù)庫2. 上組中輸出的采購訂貨單信息3. 輸入供應(yīng)商發(fā)貨信息4. 讀取原庫存量信息5. 讀取標(biāo)準(zhǔn)配件質(zhì)量信息1. 核對采購訂貨單和發(fā)貨單信息2. 核對發(fā)貨配件質(zhì)量信息和標(biāo)準(zhǔn)配件 質(zhì)量信息3. 處理過程出錯信息核對出錯質(zhì)量不合格不合格配件處理合格配件入庫處理1. 將合格標(biāo)志送回上一級調(diào)用模式2. 將核對記錄記入文件3. 修改庫存量信息4. 修改應(yīng)付款明細(xì)帳圖10-5 配件入庫處理IPO圖配件入庫處理IPO圖表示了配件管理模塊，講述了如何核對采購訂貨單合法貨單信息，核對發(fā)貨配件質(zhì)量信息和標(biāo)準(zhǔn)配件質(zhì)量信息等功能。第五章 系統(tǒng)設(shè)計總結(jié)項(xiàng)目

15、實(shí)施中各個工作流程及時間分布項(xiàng)目開發(fā)的編寫 1天業(yè)務(wù)流程圖設(shè)計 2天數(shù)據(jù)流程圖設(shè)計 1天E-R圖設(shè)計 1天U/C矩陣設(shè)計 2天HIPO圖設(shè)計 2天文檔修改、定稿 1天本人系統(tǒng)設(shè)計特點(diǎn)優(yōu)點(diǎn)：本系統(tǒng)具有較強(qiáng)的直觀性，設(shè)計完整，能較好的體現(xiàn)系統(tǒng)的設(shè)計構(gòu)思；缺點(diǎn)：設(shè)計的有些方面有點(diǎn)簡單，有很多地方還需進(jìn)一步分析改進(jìn)。目 錄前言1第一部分項(xiàng)目管理與計劃1實(shí)驗(yàn)1制定項(xiàng)目計劃1實(shí)驗(yàn)2 項(xiàng)目可行性分析1第二部分系統(tǒng)分析1實(shí)驗(yàn)3項(xiàng)目需求收集1實(shí)驗(yàn)4用例建模1實(shí)驗(yàn)5 通過用例獲取概念數(shù)據(jù)模型1實(shí)驗(yàn)6 將概念數(shù)據(jù)模型轉(zhuǎn)換為對象關(guān)系模型1實(shí)驗(yàn)7 分析類圖建模（序列圖、交互圖、狀態(tài)圖、活動圖）1實(shí)驗(yàn)8確定設(shè)計方案（*）

16、1第三部分系統(tǒng)設(shè)計1實(shí)驗(yàn)9物理數(shù)據(jù)庫設(shè)計1實(shí)驗(yàn)10確定系統(tǒng)構(gòu)架等設(shè)計元素、設(shè)計類圖建模1實(shí)驗(yàn)11 界面設(shè)計1第四部分系統(tǒng)實(shí)現(xiàn)1實(shí)驗(yàn)12 系統(tǒng)實(shí)現(xiàn)代碼（*）1附錄：項(xiàng)目成員分工情況1備注：*為選做實(shí)驗(yàn)。第一部分實(shí)驗(yàn)一：制定項(xiàng)目計劃實(shí)驗(yàn)二：制定項(xiàng)目計劃從經(jīng)濟(jì)上分析項(xiàng)目的可行性投資成本印第安漢堡餐品預(yù)定系統(tǒng)在投資成本上包括兩方面，一次性成本和續(xù)生成本。一次性成本包括基建投資和其他一次性投資，具體是指與項(xiàng)目活動、系統(tǒng)開發(fā)和系統(tǒng)啟用有關(guān)的費(fèi)用，包括在該信息系統(tǒng)開發(fā)過程中全部一次性投入，如系統(tǒng)開發(fā)、新硬件和軟件的采購，用戶培訓(xùn)、站點(diǎn)準(zhǔn)備、數(shù)據(jù)或系統(tǒng)轉(zhuǎn)化。根據(jù)搜集到的資料顯示，印第安漢堡的餐品預(yù)定系統(tǒng)的一次

17、性成本如下所示：PC機(jī)：2臺，5000*2=10000元Microsoft SQL Server 2005（1套）：5000元Microsoft Server2008（1套）：10000元打印機(jī)1臺：1000元人員培訓(xùn)：7人/2000元，合計14000元總計：本系統(tǒng)開發(fā)的一次性投入為40000元，并且新系統(tǒng)需在6個月內(nèi)實(shí)現(xiàn)。經(jīng)常性支出是指由于正在進(jìn)行的系統(tǒng)演化和使用而產(chǎn)生的費(fèi)用，例如應(yīng)用軟件維護(hù)、逐漸增加的數(shù)據(jù)存儲費(fèi)用、增加的溝通、新軟件和硬件租借以及消費(fèi)用品和其他支出等。根據(jù)搜集到的資料顯示，在印第安漢堡的餐品預(yù)定系統(tǒng)中，這種經(jīng)常性投入表現(xiàn)為續(xù)生成本，并且需要連續(xù)投資5年，具體如下所示：預(yù)定

18、系統(tǒng)的維護(hù)：1000元/年*5年=5000元每年增加的數(shù)據(jù)存儲費(fèi)用：5000元/年*5年=25000元消費(fèi)用品支出：800元/年*5年=4000元其他支出：1000元/年*5年=5000元綜上可得，印第安漢堡的餐品預(yù)定系統(tǒng)為15000美元/年，折算為現(xiàn)值為96862元。具體如下圖所示。（貼現(xiàn)率為10%時）投資收益由于我們的系統(tǒng)結(jié)構(gòu)較為簡單，功能單一，初期投入后利潤也不會有太多。我們同樣將系統(tǒng)運(yùn)行后的投資收益分為一次性收益和經(jīng)常性收益。根據(jù)預(yù)測，印第安漢堡的餐品預(yù)定系統(tǒng)的投資收益如下所示：1 一次性收益：無。2 經(jīng)常性收益：（1）由于系統(tǒng)的改進(jìn)而增加的收益：2000元/年*5=10000元（2）

19、市場占有率的提高而增加的收益（假設(shè)市場占有率以每年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）不可定量的其他收益：5年共2284元開發(fā)該訂餐系統(tǒng)，當(dāng)其投入運(yùn)行后，每年的凈收益為25000元，再考慮貨幣的時間價值，系統(tǒng)每年的凈收益如下所示。（貼現(xiàn)率為10%時）綜上可知，五年內(nèi)系統(tǒng)的總收益為94770美元。成本/收益分析通過上述成本收益的分析可知，當(dāng)貼現(xiàn)率為10%時，新開發(fā)的信息系統(tǒng)總成本為96862元，總收益為947

20、70元。由于總成本是大于總收益的，所以系統(tǒng)越運(yùn)行，越虧損，該信息系統(tǒng)不具備經(jīng)濟(jì)上的可行性。我們調(diào)整貼現(xiàn)率可知，當(dāng)貼現(xiàn)率為5%時，系統(tǒng)具有經(jīng)濟(jì)上的可行性。（貼現(xiàn)率為5%）總成本為104942美元?？偸找鏋?08237美元。（貼現(xiàn)率為5%）成本收益分析投資回收期為第4.58年。投資回報率為3.14%凈收益108237美元-104942美元=3295美元。從經(jīng)濟(jì)上考慮，當(dāng)貼現(xiàn)率為5%是，新系統(tǒng)在經(jīng)濟(jì)上具有可行性。第二部分實(shí)驗(yàn)三：項(xiàng)目需求收集我們選擇訪談的形式進(jìn)行需求收集，分別對顧客、服務(wù)員、廚師進(jìn)行提問，以下是我們設(shè)計的問題針對顧客：1 您更偏重哪種口味的漢堡 飲料 冰淇淋2 能說一下漢堡 飲料 冰

21、淇淋與季節(jié)的關(guān)系嗎3 您希望多長時間拿到您的定餐4 您一般什么時候來店里消費(fèi)5 您希望我們店通過什么方法實(shí)現(xiàn)個性化推薦，發(fā)傳單 貼海報 咨詢服務(wù)員針對服務(wù)員：1 一天中什么時候是消費(fèi)的最高峰2 你覺得什么樣的界面操作比較方面3 你覺得系統(tǒng)存在什么樣的問題4 您對系統(tǒng)有什么樣的改進(jìn)意見5 您覺得訂餐系統(tǒng)對企業(yè)帶了的效益體現(xiàn)在哪里針對廚師：1 您希望多長時間來準(zhǔn)備漢堡 飲料 冰淇淋2 現(xiàn)在一天大約做多少漢堡 飲料 冰淇淋 （庫存的要求）3 對這個系統(tǒng)您最不喜歡的是什么4 您對訂餐系統(tǒng)在缺貨處理上有怎樣的評價5 您覺得訂餐系統(tǒng)對你的工作有何幫助最可能得到的文檔是訪談記錄，最不可能得到的文檔是觀察筆記

22、實(shí)驗(yàn)四：用例建模我們?yōu)橛〉诎矟h堡構(gòu)建的信息系統(tǒng)主要是為了方便客戶點(diǎn)餐以及管理員及時進(jìn)行庫存控制，以減少顧客在點(diǎn)餐和取餐時的時間開銷，為印第安漢堡贏取更大的利益。一、印第安漢堡點(diǎn)餐系統(tǒng)的用例圖如下所示。二、印第安漢堡點(diǎn)餐系統(tǒng)的用例描述1.顧客通過印第安漢堡的點(diǎn)餐系統(tǒng)生成訂單的用例描述用例名稱：生成訂單簡要說明：電話訂餐接線員或者前臺接到顧客的訂單，生成訂單一式三聯(lián)。參與者：電話訂餐接線員或者前臺前置條件：顧客的訂餐需求是有效的后置條件：生成正確的訂單，包括顧客的姓名、電話、住址以及訂單編號等基礎(chǔ)內(nèi)容。假設(shè)條件：電話訂餐接線員或者前臺已經(jīng)成功登錄訂餐系統(tǒng)基本操作流程：（1）接線員或者前臺接收到顧客

23、的有效訂餐（2）在訂餐系統(tǒng)中輸入顧客需求的餐品名稱進(jìn)行查詢，比對顧客對餐品的需求量和庫存量。（3）在庫存充足的條件下，點(diǎn)擊進(jìn)入目標(biāo)餐品的預(yù)訂頁面，要求顧客報送姓名、電話及住址信息，點(diǎn)擊“確認(rèn)按鈕”生成訂單，此項(xiàng)操作只針對電話訂餐接線員，如為前臺訂餐，直接在庫存充足的情況下，點(diǎn)擊“確定”按鈕生成訂單一式三聯(lián)即可。（4）系統(tǒng)將顧客的訂單信息寫入數(shù)據(jù)庫，以進(jìn)行庫存管理?？蛇x操作流程：（1）顧客有信息輸入錯誤的，前臺人員不予以確認(rèn)原錯誤訂單，再按照顧客的正確信息重新生成訂單即可。（2）顧客在訂餐過程中臨時決定退訂的，操作如“顧客信息輸入有誤”同樣處理。2.管理員對數(shù)據(jù)庫中的訂單進(jìn)行管理的用例描述用例名

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

25、理簡要說明：后臺管理員根據(jù)公司業(yè)務(wù)發(fā)展的需要對點(diǎn)餐系統(tǒng)中供應(yīng)的餐品進(jìn)行增、刪、該操作。參與者：后臺管理員前置條件：點(diǎn)餐系統(tǒng)中確實(shí)存在需要修改的餐品信息后置條件：顯示更新后的餐品信息假設(shè)條件：后臺管理員使用特殊賬號正確登錄到點(diǎn)餐系統(tǒng)基本操作流程：(1) 后臺管理員在主頁面上點(diǎn)擊“增加餐品”按鈕，進(jìn)入增加餐品的二級頁面，填寫相應(yīng)信息，完成餐品增加操作。(2)后臺管理員在主頁上輸出查詢條件，選擇出需要修改的餐品（一般是餐品價格的修改），點(diǎn)擊餐品圖片進(jìn)入二級頁面，完成對餐品的修改操作。(3) 后臺管理員在主頁上輸出查詢條件，選擇出需要刪除的餐品，點(diǎn)擊餐品圖片右下方的“刪除，”完成對餐品的刪除操作。可選

26、操作流程：增加餐品的前提是庫存不為零，庫存超過一定數(shù)量的餐品系統(tǒng)顯示不能刪除餐品信息。4.印第安漢堡點(diǎn)餐系統(tǒng)對庫存量進(jìn)行管理的用例描述用例名稱：庫存控制簡要說明：系統(tǒng)根據(jù)訂單的數(shù)量和內(nèi)容減少相應(yīng)的庫存量。參與者：后臺管理員前置條件：系統(tǒng)中存在一些已經(jīng)生成的訂單后置條件：庫存量作相應(yīng)的變動假設(shè)條件：后臺管理員使用特殊賬號正確登錄到點(diǎn)餐系統(tǒng)基本操作流程：(1) 系統(tǒng)根據(jù)已經(jīng)確認(rèn)的訂單中餐品名稱和餐品數(shù)量做相應(yīng)庫存量的減少。每銷售出去一個餐品，庫存數(shù)據(jù)庫中對應(yīng)餐品的庫存量相應(yīng)的減一。(2) 系統(tǒng)顯示每種餐品剩余庫存量以便管理員及時同有關(guān)部門協(xié)調(diào)，增加相應(yīng)餐品的供給?？蛇x操作流程：庫存量為零時，系統(tǒng)提

27、示不能進(jìn)行相應(yīng)的庫存減少的操作。5送貨員向顧客供應(yīng)訂貨的用例描述用例名稱：供應(yīng)訂貨簡要說明：送貨員憑借其中一份訂單與顧客錢貨兩清，完成整個訂餐過程參與者：送貨員前置條件：顧客完成“點(diǎn)餐”用例，且餐品未送達(dá)。后置條件：交易完成，刪除相應(yīng)訂單假設(shè)條件：顧客提交了有效的點(diǎn)餐需求基本操作流程：(1) 送貨員憑借訂單與顧客完成交易后，向有關(guān)管理部門提示“送貨成功”。(2) 系統(tǒng)根據(jù)訂單中的餐品名稱和餐品數(shù)量作相應(yīng)庫存量的減少?？蛇x操作流程：如果交易不成功的話，送貨員應(yīng)及時提醒后臺管理員，后臺管理員應(yīng)及時刪除相應(yīng)訂單。實(shí)驗(yàn)五：通過用例獲取概念數(shù)據(jù)模型概念數(shù)據(jù)模型是對組織數(shù)據(jù)的描繪，它以一種獨(dú)立于現(xiàn)實(shí)的方式

28、說明了數(shù)據(jù)的結(jié)構(gòu)和數(shù)據(jù)之間的相互關(guān)系。本次實(shí)驗(yàn)通過對前面用例進(jìn)行分析，并結(jié)合我們訂餐系統(tǒng)的功能和需求，建立概念數(shù)據(jù)模型，具體步驟如下：1、標(biāo)識用例中的類通過觀察用例并結(jié)合實(shí)際分析，我們可以抽象出以下幾個類：Admin（管理員），Order（訂單），Customer（顧客），Product（產(chǎn)品），以及關(guān)聯(lián)類Lineitem（訂單行項(xiàng)目）。2、確定每一個類的屬性 用例中沒有提供關(guān)于屬性的所有詳細(xì)資料，因此我查看了與“訂單”用例相關(guān)文檔，并結(jié)合本系統(tǒng)的功能需求，將屬性分配到類。Admin（管理員）：AdminId（管理員號），AdminName（管理員姓名），AdminPsd（管理員密碼），Adm

29、inType（管理員類型）Order（訂單）：OrderId（訂單號），OrderDate（訂單時間），SubTotal（小計），TotalAmount（總數(shù)量），Customer（顧客）：CustId（顧客號），CustomerName（顧客姓名），CustPhone（顧客電話）CustAddress（顧客地址）Product（產(chǎn)品）：ProId（產(chǎn)品號），ProName（產(chǎn)品名稱）， ProPrice（產(chǎn)品單價），ProPicture（產(chǎn)品圖片），ProAbstract（產(chǎn)品介紹），ProAmount（產(chǎn)品庫存）LineItem（訂單行項(xiàng)目）：Quantity（數(shù)量），ActualPric

30、e（實(shí)際價格），LineAmount（項(xiàng)目總數(shù)量）3、確定標(biāo)識符即選擇一個屬性作為這個類的唯一標(biāo)識符。在此我們選擇AdminId（管理員號）、OrderId（訂單號、CustId（顧客號）、ProId（產(chǎn)品號）為標(biāo)識符4、考慮屬性的性質(zhì)在此，除了普通的屬性以外，我們認(rèn)為顧客聯(lián)系方式應(yīng)除了常用的一個以外，至少一個備用，所以CustPhone（顧客電話）為多值屬性，訂單的ubTotal（小計），TotalAmount（總數(shù)量），產(chǎn)品的ProAmount（產(chǎn)品庫存）可由其他數(shù)據(jù)確定，應(yīng)為導(dǎo)出屬性。5、屬性與屬性之間的關(guān)系通過分析我們可以知道，一個顧客可以下多個訂單，一個訂單只能對應(yīng)一個顧客購買；一個

31、管理員（前臺）可以處理多個訂單，但每個訂單對應(yīng)一個管理員，因此Customer和Order，Asmin和Order的關(guān)系是一對一的。每個訂單可包含多種產(chǎn)品，每個產(chǎn)品可以包括在不同的訂單里，因此Product和Order為多對多的關(guān)系，用關(guān)聯(lián)類LineItem來表示。6、建立概念數(shù)據(jù)模型 綜上所述，我們建立的概念數(shù)據(jù)模型如下圖所示：實(shí)驗(yàn)六：將概念數(shù)據(jù)模型轉(zhuǎn)換為對象關(guān)系模型對象關(guān)系數(shù)據(jù)模型是帶有面向?qū)ο髷U(kuò)充的關(guān)系數(shù)據(jù)模型，以關(guān)聯(lián)表或關(guān)系的形式描繪數(shù)據(jù)。本次實(shí)驗(yàn)基于前面概念數(shù)據(jù)模型的建立，將其轉(zhuǎn)化為對象關(guān)系，接著將所有關(guān)系合并為最終的、綜合的一組關(guān)系，其步驟如下：1、將類轉(zhuǎn)化為對象關(guān)系類的標(biāo)識符成為

32、該對象關(guān)系的主鍵，類的其他屬性成為該對象關(guān)系的非主鍵屬性。則對象關(guān)系如下：Admin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，OrderDate，SubTotal，TotalAmount）Customer（CustId，CustomerName，CustPhone，CustAddress）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，ProAmount）2、為1：n關(guān)系安排外鍵在此系統(tǒng)中，有兩個一對多的關(guān)系，根據(jù)將1方的主鍵增加為n方的外鍵，則order關(guān)系將被修改為包

33、含CustId 和AdminId，作為外鍵。Order（OrderId，CustId，AdminId，OrderDate，SubTotal，TotalAmount）3、最后轉(zhuǎn)化關(guān)聯(lián)類 在Order和Product之間有一關(guān)聯(lián)類LineItem，其可映像為對象關(guān)系，并用兩個類的主鍵OrderId 和ProId的組合作為他的主鍵。LineItem（OrderId ，ProId，Quantity，ActualPrice，LineAmount）4、規(guī)范化關(guān)系對象，進(jìn)一步細(xì)化由于Customer允許通過接收多值屬性違背了第一范式，因而Customer不是一個良構(gòu)關(guān)系，而是一個對象關(guān)系，又因?yàn)槲覀冞M(jìn)一步討

34、論決定接收純粹的關(guān)系模型，因此將Customer分為關(guān)系，為：Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，CustPhone）5、對象關(guān)系模型 經(jīng)過一步步的細(xì)化，我們產(chǎn)生了6個對象類，導(dǎo)出的對象關(guān)系模型如下：Admin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，CustId，AdminId，OrderDate，SubTotal，TotalAmount）LineItem（OrderId ，ProId，Quantity，ActualPrice，LineAmount）

35、Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，ProAmount）Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，CustPhone）實(shí)驗(yàn)七：分析類圖建模這一部分通過圖對系統(tǒng)進(jìn)行描述1.順序圖：交互圖是幫助在一個用例的分析類之間分配責(zé)任并說明類對象之間的相互交互的圖，常用的交互圖的類型是順序圖，它以時間順序的方式說明類的對象之間的交互。下圖為按照指導(dǎo)原則描繪的“預(yù)訂”用例的順序圖：圖中詳細(xì)描述了“預(yù)定”用例的順序圖：參與者：Customer選擇一個或多個產(chǎn)品調(diào)用

36、該用例，這個消息/select item（選擇產(chǎn)品項(xiàng)）表明，它被傳給：OrderForm。表單將信息傳遞給控制對象：OrderControl，于是創(chuàng)建訂單。控制對象將創(chuàng)建新訂單的責(zé)任傳給了：Order，：Order創(chuàng)建一個新訂單。類似的，控制將增加一個項(xiàng)目的責(zé)任傳遞給了：LineItem。它來創(chuàng)建一個新的項(xiàng)目。或者，：Order對象可以負(fù)責(zé)增加：LineItem對象。2.活動圖：活動圖和順序圖相似，但兩個圖的重點(diǎn)不同，順序圖在于說明一個程序中的控制流，而活動圖說明系統(tǒng)中活動到活動的控制流，什么活動可以并行進(jìn)行，和任何通過流的可選路徑。“預(yù)定”用例的活動圖： 子流程同步的活動圖：3.狀態(tài)圖：狀態(tài)

37、圖通過制定一個對象在自己的生存期間響應(yīng)時間而經(jīng)歷的狀態(tài)序列以及對這些事件的響應(yīng)來描述對象的行為。一個對象的狀態(tài)是在對象生存期間的一個條件或情況，在這個時間它滿足某些條件，執(zhí)行某些活動或等待某些事件。可以認(rèn)為對象的活動圖是狀態(tài)圖的一個特例。 例如，對象訂單的狀態(tài)經(jīng)歷創(chuàng)建、供應(yīng)、完成，它的狀態(tài)圖如下：4.分析類圖： 分析類圖說明分析類和這些類之間的關(guān)系，有兩種關(guān)系結(jié)構(gòu)關(guān)系和行為關(guān)系，結(jié)果方面從數(shù)據(jù)建模中可以獲得，分析類圖的行為方面可以從順序圖或通信圖導(dǎo)出。下圖是“預(yù)訂”用例的一個分析類圖：OrderOrderOrderIdOrderDateSubTotalTotalAmount/create or

38、der()/get order info()/update order info()CustomerCustIdCustomerNameCustPhoneCustPhone/get customer info()/charge customer()ProductProIdProNameProPrice/get products info()/update inventoryLineItemQuantityActualPriceLineAmount/add item()/get lineitems()/write order lineitems()BUYOrderControl/select i

39、tem()/confirm order()/calc total()OrdertForm/select item()/confirm order()第三部分實(shí)驗(yàn)八：物理數(shù)據(jù)庫設(shè)計物理數(shù)據(jù)庫設(shè)計是對系統(tǒng)存儲結(jié)構(gòu)和存取方法等依賴于具體計算機(jī)結(jié)構(gòu)的各項(xiàng)物理設(shè)計措施的設(shè)計，涉及訪問的效率考慮因素比如響應(yīng)時間和事務(wù)吞吐量，本實(shí)驗(yàn)旨在確保用戶在運(yùn)行查詢時不必等待不合理的時間，從而有效執(zhí)行任務(wù)。1、關(guān)系對象屬性特性描述 在實(shí)驗(yàn)六中，我們的到如下的對象關(guān)系A(chǔ)dmin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，CustId，AdminId，OrderD

40、ate，SubTotal，TotalAmount）LineItem（OrderId ，ProId，Quantity，ActualPrice，LineAmount）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，ProAmount）Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，CustPhone） 根據(jù)上述對象關(guān)系，結(jié)合邏輯數(shù)據(jù)模型以及實(shí)際情況，分析了各個屬性的特征，如數(shù)據(jù)類型、設(shè)計域、數(shù)據(jù)的完整性（默認(rèn)值、是否為空、控制范圍、參照完整性）等，具體涉及如下表所示：

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

42、系統(tǒng)管理員Order字段名數(shù)據(jù)類型是否允許為空鍵或索引說明OrderIDInt(20)否主鍵唯一；系統(tǒng)自動賦予CustIDInt（20）否參照顧客表AdminIDInt(20)否參照管理員表 OrderDatedatetime否系統(tǒng)自動生成SubTotalNumeric(18,2)否根據(jù)LineItem表生成TotalAmountInt是根據(jù)LineItem表生成LineItem字段名數(shù)據(jù)類型是否允許為空鍵或索引說明OrderIDInt(10)否主鍵參照訂單表ProIdInt(20)否主鍵參照產(chǎn)品表QuantityInt（10）否ActualPriceNumeric(18,2)否LineAmo

43、untNumeric(18,2)否系統(tǒng)自動生成Product 字段名數(shù)據(jù)類型是否允許為空鍵或索引說明ProIdInt(20)否主鍵唯一；系統(tǒng)自動賦予ProNameNvarchar(50)否唯一ProPriceNumeric(8,2)否ProPicturImage否唯一ProAbstractNtest否唯一；非空ProAmountNtest是參照留言表2、物理數(shù)據(jù)庫文件組織及索引設(shè)計根據(jù)實(shí)際情況和需求分析，我們估計了表的行的大小和數(shù)目如下圖所示。表名行對象數(shù)目每個行對象的字節(jié)數(shù)Admin2000200Order5000000100LineItem1000000040Product4000200C

44、ustomer500000200CustPhone100000050我們假設(shè)選擇的塊大小是由4000個可用字節(jié)的4k（4096個字節(jié)）。在Admin表的例子中，分塊因子4000/200。Admin表的大小是2000/20。Admin表的掃描時間是100*2.5ms為0.25s。類似的可以算出其余幾個表的計算如下圖表名行對象數(shù)目每行字節(jié)數(shù)分塊因子（BF）塊數(shù)掃描時間（秒）是否需要索引Admin2000200201000.25否Order500000010040125000312.5是LineItem1000000040100100000250是Product4000200202000.5否Cus

45、tomer5000002002025000625是CustPhone100000050801250031.25是上面的計算表明索引這六個表的6個主鍵AdminId、OrderId、（OrderId ，ProId）、ProId、CustId、（CustId，CustPhone）。主鍵一般是最常被訪問的屬性。可將Admin和Product存儲在數(shù)據(jù)庫服務(wù)器的高速緩沖去。即使沒有被緩存，掃描時間也只不過0.25s和5s，沒有必要索引除了主鍵之外的任何屬性。3）Order、LineItem、Customer和CustPhone是大表，并且需要索引來加快查詢的速度。可以通過索引具有大量不同值的外鍵提高檢

46、索速度。很明顯AdminId、OrderId、ProId、CustId都是很好的索引候選。4）索引被頻繁訪問并具有相對大量不同質(zhì)的非屬性鍵如CustomerName也可作為索引。數(shù)據(jù)九：確定系統(tǒng)構(gòu)架等設(shè)計元素、設(shè)計類圖建模實(shí)驗(yàn)十：界面設(shè)計印第安漢堡點(diǎn)餐系統(tǒng)是基于提高點(diǎn)餐周轉(zhuǎn)速率以及更好地進(jìn)行庫存控制而開發(fā)的，在界面設(shè)計上我們也充分考慮到快餐店的經(jīng)營特點(diǎn)，盡可能地提供便捷的頁面操作方式，提高漢堡店的經(jīng)營效率。1.印第安系統(tǒng)界面設(shè)計是遵循的原則（1）通用原則 界面色彩要求：計算機(jī)屏幕的發(fā)光成像和普通視覺成像有很大的不同，應(yīng)該注意這種差別作出恰當(dāng)?shù)纳蚀钆洹＠巛p松的淡彩為主配色，灰色系為主配色等等

47、。我們的點(diǎn)餐系統(tǒng)采用橙黃的為基調(diào)，旨在提供一種溫馨、熱情的界面感覺。（2）界面平面版式要求：系統(tǒng)樣式排版整齊劃一，盡可能劃分不同的功能區(qū)域于固定位置，固定的格式，方便用戶導(dǎo)航使用；排版不宜過于密集，保留一定的“留白”區(qū)域，減輕查看時的視覺疲勞。 （3）數(shù)據(jù)顯示集中原則：各種列表在頁面中往往是傳遞信息的核心，盡量集中的表現(xiàn)出來，并提供必要的關(guān)聯(lián)數(shù)據(jù)、表等恰當(dāng)?shù)慕M織起來，并且在視覺上使用戶很容易察覺數(shù)據(jù)之間的關(guān)系，并方便查看、編輯等。（4）主次分明原則：頁面中同時分布較多欄目的情況下，按照頁面的伸展方向，即由上到下，有左到右，根據(jù)瀏覽的方向，重要的內(nèi)容應(yīng)該在左邊最易注意的位置，導(dǎo)航等置于頁面頭部固定位置。使導(dǎo)航等重要內(nèi)容始終處于用戶的視野之中.頁面右邊一般是一些當(dāng)前頁面主要操作的擴(kuò)展、選項(xiàng)等內(nèi)容。 （5） 變化（對比）原則：在頁面主體內(nèi)容部分往往有很多文本信息，它是需要用戶認(rèn)真閱讀的部分，只在文本字體、色彩上增加格式的變化，如加粗、下劃線、行前導(dǎo)符、鏈接文本的不同狀態(tài)定義等，就可以將冗長的文檔、表格等組織的很有條理；冗長的內(nèi)容“層次“就有了變化，更容易辯識(Readable)；在美學(xué)角度增加了相臨部分間的對比。 （6） 頁面留白：頁面留白同時也是一種增加可讀性的方式。在文字區(qū)域防止用戶讀完一行無法定位下一