碩士學(xué)位論文之快捷酒店管理系統(tǒng)設(shè)計與前端實現(xiàn)

1、摘 要目前，我國快捷型酒店發(fā)展十分迅速，但是相對于酒店的快速擴(kuò)展，酒店管理軟件的更新卻不是如此及時，快捷酒店相對于的操作應(yīng)該是十分簡單明了，但是傳統(tǒng)酒店管理系統(tǒng)操作十分復(fù)雜，導(dǎo)致操作員需要大量時間學(xué)習(xí)如何操作。本文主要介紹了如何針對快捷酒店的需求，通過flex編寫的前臺程序，和后臺迅速交互。達(dá)到使客戶認(rèn)為操作簡單并且容易上手。介紹flex關(guān)于ria的開發(fā)流程及flex用作客戶端編程所帶來的好處。分析整個酒店管理系統(tǒng)的架構(gòu)，分析各個功能模塊的基本數(shù)據(jù)結(jié)構(gòu)，接口，功能流程等。最后對系統(tǒng)的特點及不足之處進(jìn)行總結(jié)。關(guān)鍵詞：flex，ria，快捷酒店，模塊功能，系統(tǒng)架構(gòu)abstractat presen

2、t, there is an increasing development of inn hotel in china. however, the hotel management software is not updating in time. relative to the complex operation of traditional hotel management operating system, the operation of inn hotel should be simple and convenient. so staffs do not need spend too

3、 much time on learning how to handle it.this article gives an introduce of how to use client which is written by flex to interact with server, and finally makes it meet the inn hotel requirements. the article also presents the development process of ria and advantages of flex programming as client.

4、then it makes a further analysis of management system frame as well as basic data structure of different functional model and interface. in the end, the article gives a brief summary of the characteristics and inadequacies for this management systemkey words：flex , ria, inn hotel, functional model,

5、system frame 目錄摘要iabstractii圖目錄iii第1章 緒論11.1 課題背景11.2 發(fā)展及現(xiàn)狀11.3 研究的目標(biāo)和內(nèi)容2第2章 相關(guān)技術(shù)和方法32.1 ria介紹32.2 flex技術(shù)簡介32.3 remoteobject介紹42.4 spring框架簡介42.5 hibernate框架簡介5第3章 系統(tǒng)的需求分析及概要設(shè)計73.1 系統(tǒng)的需求分析73.2 系統(tǒng)的總體設(shè)計73.3 模塊設(shè)計83.3.1 功能介紹83.4 主要功能模塊103.4.1 入住管理模塊設(shè)計113.4.2 賬務(wù)及現(xiàn)付賬模塊設(shè)計153.4.3 報表管理模塊設(shè)計173.4.4 系統(tǒng)管理與維護(hù)模塊設(shè)計

6、183.5 數(shù)據(jù)庫設(shè)計193.5.1 表和視圖的設(shè)計193.5.2 存儲過程設(shè)計253.6 其他功能模塊設(shè)計26第4章 快捷酒店管理系統(tǒng)的實現(xiàn)274.1 主要開發(fā)技術(shù)274.2 用戶界面實現(xiàn)284.2.1 登錄模塊的實現(xiàn)294.2.2 預(yù)定及登記模塊的實現(xiàn)30第5章 總結(jié)與展望385.1 總結(jié)385.2 展望38致謝39參考文獻(xiàn)40圖目錄圖3.1系統(tǒng)總體設(shè)計圖8圖3.2酒店業(yè)務(wù)流程圖11圖3.3顧客預(yù)定用例圖12圖3.4顧客登記用例圖12圖3.5團(tuán)隊/協(xié)議單位入住用例圖13圖3.6房間狀態(tài)圖14圖3.7房間狀態(tài)圖圖例15圖3.8顧客賬務(wù)處理時序圖16圖3.9顧客房費管理用例圖16圖3.10會員

7、消費示意圖17圖3.11營業(yè)日報報表圖18圖3.12權(quán)限查詢流程圖19圖3.13登記單模型圖21圖3.14顧客管理模型圖22圖3.15會員管理模型圖23圖3.16房價信息模型圖24圖3.17房間信息模型圖25圖3.18公司級顧客信息修改存儲過程26圖3.19酒店夜審存儲過程26圖3.20報表生成存儲過程26圖4.1酒店登錄界面圖29圖4.2酒店注冊界面圖29圖4.3選擇酒店頁面30圖4.4顧客預(yù)定界面31圖4.5步入散客顧客登錄界面32圖4.6錯誤或為空提示框33圖4.7已有顧客修改或增加信息界面34圖4.8增加預(yù)收款界面35圖4.9添加其它信息界面36圖4.10添加周期收費界面37第1章 緒

8、論目前，我國快捷連鎖酒店企業(yè)還沒有真正屬于自己的適合自己發(fā)展需要的快捷酒店的管理軟件，大的連鎖酒店如：如家，漢庭用的都是自己酒店內(nèi)部開發(fā)的酒店管理系統(tǒng)。其他快捷酒店管理系統(tǒng)則主要來自各種星級酒店的管理系統(tǒng)。與自己的酒店業(yè)務(wù)辦理有一些出入。因此我實習(xí)所在的公司，準(zhǔn)備開發(fā)出一套專門針對快捷酒店快速反應(yīng)及符合其業(yè)務(wù)需求的管理軟件。不僅滿足酒店的管理需求，也能充分讓住客體驗到快捷酒店的方便及實用性。1.1 課題背景本文的課題主要來自作者的工程實踐，以杭州綠云軟件有限公司的酒店管理系統(tǒng)的開發(fā)為背景，利用公司已開發(fā)的星級酒店管理系統(tǒng)，來設(shè)計一個針對快捷酒店的管理系統(tǒng)。同大多數(shù)b/s架構(gòu)模式的系統(tǒng)相似，快捷

9、酒店管理系統(tǒng)主要分為如下幾個模塊：前端，應(yīng)用服務(wù)器端，數(shù)據(jù)庫服務(wù)器端。其中，前臺用flex編寫，使用remoteobject與java端進(jìn)行通信。然后通過java端程序的控制，從數(shù)據(jù)庫服務(wù)器中交換數(shù)據(jù)。由于公司已經(jīng)開發(fā)過星級酒店的管理系統(tǒng)，因此后臺可以打一個分支即可重用以前的java代碼。作者的主要任務(wù)是開發(fā)好前端flex代碼，根據(jù)客戶所需求的簡單快捷的操作來設(shè)計編寫前端界面。開發(fā)快捷酒店管理系統(tǒng)的價值如下：(1)使酒店操作員能夠輕易上手并且能夠增加前臺的工作效率。(2)采用創(chuàng)新的flex技術(shù)使得原本影響flex程序性能的問題能得以解決。(3)為管理層決定酒店的消費定價等提供更多的數(shù)據(jù)分析及決

10、策。1.2 發(fā)展及現(xiàn)狀酒店管理軟件是最早在西方發(fā)達(dá)國家最先使用的，像希爾頓，喜來登等國際型大酒店都有專門的軟件公司為他們量身定做管理軟件。因此，這些酒店的管理效率及公司運作方面都是做的比較好的。從現(xiàn)代科技的發(fā)展來看，一個好的酒店必須是軟硬件配合的很好才能發(fā)揮最大的效率，硬件當(dāng)然是指酒店的裝潢服務(wù)等，而軟件則是一套方便智能的管理系統(tǒng)。社會經(jīng)濟(jì)在不斷發(fā)展，酒店在服務(wù)行業(yè)扮演的角色也越來越重要，一個酒店的管理和服務(wù)水平直接影響到酒店的形象和聲譽1。酒店管理系統(tǒng)最先西方發(fā)達(dá)國家率先發(fā)展起來的，像喜來登，希爾頓等國際型連鎖酒店，它們都有一套完善的酒店管理系統(tǒng)來提高酒店管理的效率，并且分析數(shù)據(jù)給高層用來決

11、策。在上世紀(jì)90年代，酒店業(yè)因為競爭激烈而經(jīng)營狀況十分艱難2。他們最先了解并且使用了erp這個概念，也就是企業(yè)資源企劃。使得企業(yè)的管理顯得十分井井有條。酒店業(yè)也不再局限于傳統(tǒng)意義上的價格惡性競爭,它將是各酒店集團(tuán)連鎖品牌（集團(tuán)端）和各酒店之間運用網(wǎng)絡(luò)系統(tǒng)的整體營銷和管理上的競爭3。目前，國內(nèi)快捷酒店管理軟件遇到的問題有很多。還存在很多不足和問題，酒店行業(yè)作為服務(wù)業(yè)的典型，在此項技術(shù)面前，卻又一次落伍。世界范圍內(nèi)的酒店管理集團(tuán)，可以談得上成功運用客戶信息管理的寥寥無幾，諸多客戶信息管理廠商，也沒有能夠及時拿出一套切實可行的針對酒店行業(yè)的全面解決方案。1.3 研究的目標(biāo)和內(nèi)容本文以某快捷酒店管理系

12、統(tǒng)項目為例，對快捷酒店管理系統(tǒng)項目研發(fā)過程中的需求分析，架構(gòu)設(shè)計，產(chǎn)品測試及性能分析進(jìn)行了實質(zhì)性的研究。研究的目標(biāo)是：結(jié)合快捷酒店管理系統(tǒng)項目的特點和開發(fā)過程，分析其設(shè)計模式及架構(gòu)。分析各個功能模塊的基本數(shù)據(jù)結(jié)構(gòu)，接口，功能流程等。探討如何設(shè)計出適用于快捷酒店管理系統(tǒng)項目的系統(tǒng)架構(gòu)及對此系統(tǒng)完成后進(jìn)行的系統(tǒng)性能進(jìn)行詳細(xì)分析。分析包括客戶端程序在長時間運行時對操作系統(tǒng)資源占用和高并發(fā)操作時是否影響系統(tǒng)性能及穩(wěn)定性。第2章 相關(guān)技術(shù)和方法2.1 ria介紹ria（rich internet applications）富互聯(lián)網(wǎng)應(yīng)用，傳統(tǒng)的英特網(wǎng)應(yīng)用程序都是把大量的對數(shù)據(jù)的處理都交給服務(wù)器端，網(wǎng)絡(luò)的表

13、示層只是一些html編寫的靜態(tài)頁面。隨著it技術(shù)的不斷飛躍，傳統(tǒng)的基于頁面的系統(tǒng)已經(jīng)不能滿足客戶的需求，主要原因就是很多時候客戶端只需要從服務(wù)器端得到想要的數(shù)據(jù)，頁面的基本內(nèi)容不需要改變，但服務(wù)器端仍然返回的是html形式的頁面。這樣加重了網(wǎng)絡(luò)的傳輸成本，同時也降低了用戶的體驗。ria 使用的是相對比較健壯的客戶端描述引擎, 能夠提供比傳統(tǒng)瘦客戶端內(nèi)容更密集、響應(yīng)速度更快和圖形更豐富的用戶界面4。ria就是區(qū)別于傳統(tǒng)的瘦客戶端而產(chǎn)生的，它把許多原來要經(jīng)過服務(wù)器端處理才能得出的數(shù)據(jù)，交由前端處理。同時，服務(wù)器端向客戶端傳輸?shù)囊部梢圆辉偈莌tml，而是客戶端所需要的數(shù)據(jù)集。ria引擎接收瀏覽器發(fā)出

14、的請求后，調(diào)用本地的業(yè)務(wù)邏輯處理組件（一般是網(wǎng)頁腳本語言）異步轉(zhuǎn)發(fā)該請求到服務(wù)器；服務(wù)器給予應(yīng)答后，ria引擎再利用自身的客戶端框架程序處理數(shù)據(jù)和和樣式特效對頁面進(jìn)行包裝，反饋給瀏覽器顯示5。 2.2 flex技術(shù)簡介flex是由adobe公司發(fā)布的r ia應(yīng)用程序框架,它提供了豐富的用戶界面組件, 其開發(fā)模型由actionscrip t3 (兼容ecmascrip t這個國際標(biāo)準(zhǔn)的面向?qū)ο蟮哪_本語言) ,mxml 模型描述語言(基于xml,實現(xiàn)標(biāo)簽化的定義方式,可用于可視化的編輯) ,以及其他的擴(kuò)展類庫組成的6。它與adobe發(fā)布的另一款產(chǎn)品flash是一個模式。flex和flash一樣都是

15、生成.swf文件運行。但相對于flash動畫有多幀，flex制作出來的界面只有兩幀。第一幀是預(yù)加載，第二幀就得到了我們想要的頁面。actionscript 3.0 是adobe發(fā)布的一種面向?qū)ο缶幊陶Z言,它提供mxml 所不具備的對程序流程的控制和對象操作等功能。flex 編譯器和調(diào)試器及虛擬機(jī)avm幫助把mxml 及actionscript 3.0 源代碼編譯成能夠運行在flash player 中的二進(jìn)制文件7。這點也是flex和flash相似之處，它們都運行在flash player當(dāng)中。但是flex與flash也是有明顯差別的，flex提供了一種完全面向?qū)ο蟮恼Z言actionscrip

16、t并且是跨平臺的。它打破了flash只能由專業(yè)的美工設(shè)計師來完成的局面。普通程序員也可以通過flex完成絢麗的界面效果。flex 和基于strut s ,spring , hibernate 的傳統(tǒng)j2ee 而言,可以通過amf 這種模式網(wǎng)關(guān)進(jìn)行集成flex 。從而在不影響原先應(yīng)用的情況下,ria 對表示層的功能和顯示靈活性進(jìn)行了豐富增強(qiáng)8。2.3 remoteobject介紹flex 可以利用3 種方法來實現(xiàn)與服務(wù)器端交換數(shù)據(jù)的功能， 分別是使用httpservice 組件、使用webservice 組件和使用remoteobject 組件9。在flex作為客戶端開發(fā)程序時，我們采用的是re

17、moteobject組件的方式來實現(xiàn)與java端通信。我們使用blazeds來完成java端與flex端的通信。flex與java使用remoteobject是異步通信的。也就是說，flex端發(fā)完請求之后不需要等待服務(wù)器端的響應(yīng)，可以做別的事情。remoteobject 組件和服務(wù)器之間傳遞信息采用action message format（amf） 編碼的二進(jìn)制格式，remoteobject 組件可以直接將amf 編碼的信息轉(zhuǎn)換成flex可以識別的object對象10。這樣方便了前臺對數(shù)據(jù)的處理。并且使用remoteobject比其他兩種方式占用的內(nèi)存更少。2.4 spring框架簡介spr

18、ing是一個輕量級的java開源框架，它遵循了面向?qū)ο蟮脑O(shè)計模式。并且把設(shè)計模式運用到實際開發(fā)及應(yīng)用中。spring 框架是一種在j2ee 的基礎(chǔ)上構(gòu)建起來的一個輕量級面向?qū)ο蟮目蚣軐崿F(xiàn), 它是一個分層的應(yīng)用程序開發(fā)框架, 而不是單獨某一層例如web 層開發(fā)框架11。相對于j2ee 而言,spring具有維護(hù)容易、分層清楚、速度快、代碼少、支持orm 對象關(guān)系映射和aop面向切面編程的概念等優(yōu)點12。spring所展現(xiàn)出來的兩種編程思想，一種是依賴注入（di），一種是面向方面編程（aop）。依賴注入概念上來說是程序不應(yīng)該依賴于具體，而是應(yīng)該依賴于抽象。簡單來說是在運行期由spring容器將對象

19、對其他對象的依賴關(guān)系注入到組件之中,使應(yīng)用代碼只需要直接使用已經(jīng)由容器注入的實例13。簡單來講就是以前的對象都是根據(jù)具體的類來構(gòu)造。這樣耦合比較緊密。但是利用spring之后，對象的構(gòu)造再也不依賴于具體的類。而是依賴于抽象接口。通過spring容器注入。這就是依賴注入的思想。而aop則是spring一個更加重要的思想。他的出現(xiàn)甚至改變了傳統(tǒng)的編程方式。傳統(tǒng)的編程方式是一條直線或多條直線（多線程）的思路編程。但是aop的思想是可以在這條直線上有一個切面。來運行別的代碼。這是基于動態(tài)代理來實現(xiàn)的一個編程模式。sp ring 的職責(zé)主要包括:(1) 把應(yīng)用程序的業(yè)務(wù)邏輯和業(yè)務(wù)校驗交由spring處理

20、。(2) 管理程序當(dāng)中的事務(wù)。(3) 提供和其它層對接的接口模塊。(4) 消除業(yè)務(wù)層級別的對象的依賴，已達(dá)到解耦合目的。(5) 在表示層和持久層之間增加了一個中間層, 使其不直接耦合在一起。(6) 揭示了從表示層到業(yè)務(wù)層之間的context 以此得到business services。(7) 管理程序的執(zhí)行，在執(zhí)行過程中增加邏輯處理(從業(yè)務(wù)層到持久層)14。2.5 hibernate框架簡介hibernate 是一個功能十分強(qiáng)大的開源orm框架工具, 允許開發(fā)者使用常見的java 語言特性(如封裝、繼承、多態(tài)等)實現(xiàn)對象模型和關(guān)系數(shù)據(jù)庫的相互映射, 并支持如oracle、db2、sql ser

21、ver、mysql等主流數(shù)據(jù)庫系統(tǒng)15?，F(xiàn)在，hibernate已經(jīng)是開發(fā)輕量級web程序的首選框架。其一是因為他封裝的很完善。并且程序員運用起來也比較簡單?，F(xiàn)在hibernate已經(jīng)出到了4.3.0。它的許多新的特性也讓人十分向往。hibernate對jdbc查出的數(shù)據(jù)使用了輕量級的對象封裝,向上層程序應(yīng)用提供了如同面向?qū)ο蟮臄?shù)據(jù)訪問api,減少了開發(fā)時人工使用sql和jdbc處理數(shù)據(jù)的時間,提高了軟件開發(fā)的效率16。開發(fā)人員甚至不需要知道寫sql就可以操作數(shù)據(jù)庫。這也是orm（對象關(guān)系映射）所需要解決的?，F(xiàn)階段，軟件產(chǎn)品大部分應(yīng)用到的數(shù)據(jù)庫都是關(guān)系型數(shù)據(jù)庫。而hibernate就是把關(guān)系型

22、數(shù)據(jù)庫轉(zhuǎn)換成為面向?qū)ο笳Z言所能讀懂的對象。hibernate的核心接口如下圖所示。其中transaction接口是處理控制事務(wù)的。它主要在程序中合適的地方定義事務(wù)的開始和結(jié)束。對應(yīng)于數(shù)據(jù)庫操作的事務(wù)。query和criteria接口是數(shù)據(jù)庫的查詢。configration類主要負(fù)責(zé)配置和啟動hibernate。創(chuàng)建sessionfactory實例來維護(hù)數(shù)據(jù)庫連接池17。圖2.1hibernate結(jié)構(gòu)模式圖由于hibernate只對jdbc 做了輕量級封裝, 應(yīng)用程序可以使用hibernate api對數(shù)據(jù)庫進(jìn)行操作, 也可以直接不使用hibernate提供的方便，使用jdbc 完成數(shù)據(jù)庫操作1

23、8。這樣就增加了系統(tǒng)的靈活性，由于有些復(fù)雜度較高的查詢用hibernate寫起來不僅麻煩，而且影響效率。實際工作中都是hibernate和jdbc一起用的。hibernate的優(yōu)點有許多，這里只簡單說明?？傊褂胔ibernate有利于節(jié)約開發(fā)成本和時間,提高業(yè)務(wù)應(yīng)用方面的性能,提供更靈活的和簡單的業(yè)務(wù)邏輯19。第3章 系統(tǒng)的需求分析及概要設(shè)計thef快捷酒店管理系統(tǒng)分為客戶端和服務(wù)器端兩部分，client模塊會被安裝在每一個物理機(jī)上。client主要負(fù)責(zé)響應(yīng)用戶操作，上傳數(shù)據(jù)給服務(wù)器端。server端主要負(fù)責(zé)處理數(shù)據(jù)，并返回給客戶端。3.1 系統(tǒng)的需求分析根據(jù)對快捷酒店集團(tuán)的調(diào)研，了解整個系

24、統(tǒng)中各類功能模塊協(xié)同工作需要獲取的信息，進(jìn)行歸納總結(jié)，確定了快捷酒店管理系統(tǒng)要實現(xiàn)的兩大基本的功能性需求：1.系統(tǒng)要對前臺操作員來說做到簡單快捷和易上手快捷酒店管理系統(tǒng)一個重要理念就是員工基本不需要單獨培訓(xùn)即可上崗，這樣降低了對員工的要求。2.系統(tǒng)要對管理層人員提供可分析數(shù)據(jù)的支持，以便管理層做出決策3.2 系統(tǒng)的總體設(shè)計為了將快捷酒店管理系統(tǒng)符合軟件設(shè)計的低耦合性和高可用性，在設(shè)計中完全遵守mvc的設(shè)計模式，設(shè)計了如下的分層式架構(gòu)，具體的架構(gòu)如圖3.1所示：clientconfig.xmlapplication servera1a2a3controler（java）database serv

25、era5a4jdbcconfig圖3.1系統(tǒng)總體設(shè)計圖a1：客戶端讀取config中的url地址，連接到應(yīng)用服務(wù)器端。a2：客戶端以remoteobject的方式與應(yīng)用服務(wù)器交互。a3：接受到的數(shù)據(jù)通過java端程序處理和控制。a4：java端讀取jdbc配置文件。準(zhǔn)備連接數(shù)據(jù)庫a5：java端與數(shù)據(jù)庫端進(jìn)行通信。完成操作并且返回數(shù)據(jù)。由于前端使用flex制作界面，flex和java有很多種的通信方式。提到通信，我們有兩方面的問題，一是選擇通信協(xié)議，二是選擇數(shù)據(jù)協(xié)議。通信協(xié)議如tcp，udp，http等。數(shù)據(jù)協(xié)議則是規(guī)定數(shù)據(jù)交換的格式，如json，xml，amf3等。在這個項目中，我們使用ad

26、obe提供的blazeds這個開源框架來實現(xiàn)java與flex之間的通信。它已經(jīng)為我們提供了java封裝amf3格式的方法。然后我們應(yīng)用hibernate和spring這兩個開源框架。把整個業(yè)務(wù)應(yīng)用劃分為三層，分別為表現(xiàn)層（ui），業(yè)務(wù)邏輯層（bll），和數(shù)據(jù)訪問層（dal）。這也完全體現(xiàn)了面向?qū)ο箝_發(fā)的“高內(nèi)聚，低耦合”的思想。一個軟件組件僅僅是一個使我們可以關(guān)聯(lián)不同的責(zé)任的抽象的設(shè)計實體20。綜上所述，系統(tǒng)采用的架構(gòu)設(shè)計是典型的mvc的思想。把客戶端作為視圖層。把java端不包括與數(shù)據(jù)庫交互的部分作為控制層。把java端與數(shù)據(jù)庫交互的模塊作為模型層。這種分層的架構(gòu)設(shè)計，不僅降低了系統(tǒng)的復(fù)雜

27、程度，也減輕了各個模塊的壓力。同時各模塊互相協(xié)作。也使得編程的思路更加清晰。在設(shè)計部分，主要通過對系統(tǒng)的用例圖，類圖，交互圖和狀態(tài)圖等一系列uml圖來進(jìn)行詳細(xì)的描述。并且對數(shù)據(jù)庫的設(shè)計也將進(jìn)行介紹。3.3 模塊設(shè)計快捷酒店管理系統(tǒng)分為以下幾個功能。用戶權(quán)限體系管理，客戶管理，協(xié)議單位管理，會員管理，銷售員管理，房價及傭金體系管理，預(yù)定管理，接待管理，客房中心管理，前臺收銀管理，應(yīng)收帳管理，夜審管理，報表及信息查詢。3.3.1 功能介紹用戶權(quán)限體系管理模塊主要負(fù)責(zé)區(qū)分酒店內(nèi)部不同員工所擁有的不同操作權(quán)限，比如經(jīng)理登錄后可在報表中查看當(dāng)天的營業(yè)日報，而前臺操作員登錄后則沒有報表項目顯

28、示，因此不能查看營業(yè)日報?？蛻艄芾碇饕?fù)責(zé)建立客戶檔案，主要把客戶分為團(tuán)隊和散客，而散客又分為會員，回頭客。如果客人第一次入住，則會自動更新客戶檔案。使得酒店的管理更加人性化。協(xié)議單位管理此模塊主要管理協(xié)議單位，協(xié)議單位就是和酒店有簽訂協(xié)議價的單位，酒店需要根據(jù)不同的公司分別管理其協(xié)議價格會員管理此模塊主要負(fù)責(zé)管理各個種類的會員，如金卡會員，銀卡會員，普通會員，并且管理其會員卡賬戶余額。積分兌換等。入住時系統(tǒng)會根據(jù)會員的不同程度給出合理的價格。銷售員管理銷售員管理則是對預(yù)定或者入住時，如果是有銷售員參與的話，就會對銷售員給予一定的獎勵。3

29、.3.1.6房價及傭金體系管理此房價模塊主要管理鐘點房及全日房的房價，每一個房價都有與之對應(yīng)的房價碼，各種客戶入住都有與之對應(yīng)的房價碼，才能找到與之對應(yīng)的房價。傭金管理則是如果顧客是通過第三方平臺預(yù)定并入住，則需要計算傭金給第三方平臺。預(yù)定和接待管理此模塊是酒店管理系統(tǒng)中比較重要的模塊，負(fù)責(zé)處理酒店的預(yù)定和入住的所有事物，此模塊幾乎與所有模塊都產(chǎn)生交互，此模塊直接決定了此系統(tǒng)的用戶體驗?？头恐行墓芾泶四K主要負(fù)責(zé)管理每個房間當(dāng)時的客房狀態(tài)。管理哪些房間可用，哪些不可用。并且負(fù)責(zé)房間是否打掃的狀態(tài)等。前臺收銀和應(yīng)收賬管理此功能主要負(fù)責(zé)前臺收銀和應(yīng)收賬務(wù)的

30、的管理，此功能也是有關(guān)財務(wù)。因此需要格外小心。0夜審管理此功能主要負(fù)責(zé)每天的夜間審核，需要計算賬務(wù)，生成營業(yè)日報，并且把當(dāng)天的房費去除掉，重新計算應(yīng)收款。還有需要重新計算明天的房費和房間資源。一系列有關(guān)賬務(wù)的操作都在夜審步驟里面。1報表和其他信息查詢此功能主要涉及管理層需要核對酒店的各種賬務(wù)情況和入住情況，以便更好的調(diào)整策略，使酒店的管理更加高效。3.4 主要功能模塊前面已經(jīng)介紹了系統(tǒng)的各個功能組成部分，通過對這些部分的分析，我們將系統(tǒng)分為入住管理和系統(tǒng)管理兩個大部分。入住管理主要分為：前臺預(yù)定接待，客房管理，收銀和應(yīng)收賬管理，會員和銷售員管理等。系統(tǒng)管理則主要分為

31、：店長系統(tǒng)，系統(tǒng)維護(hù)，夜審系統(tǒng)和報表系統(tǒng)等。下圖顯示了入住管理和系統(tǒng)管理的主要流程，其中起到橋梁作用的便是夜審。如圖3.2所示。r：預(yù)定狀態(tài)的登記單。i：在住狀態(tài)的登記單。s：掛賬狀態(tài)的登記單。指入住完酒店后，但并不直接付款，通過記帳的形勢方便以后一起計算。o：已經(jīng)結(jié)賬的登記單。x：已經(jīng)被取消的預(yù)定單。n：應(yīng)到未到的預(yù)訂單。w：wait狀態(tài)的登記單。d：刪除了的登記單。圖3.2酒店業(yè)務(wù)流程圖3.4.1 入住管理模塊設(shè)計入住管理模塊主要涉及客人的預(yù)定入住，房間的狀態(tài)顯示及顧客的資料管理 前臺入住用例描述入住管理主要包括顧客的預(yù)定，登記，客房管理，房價，換房及排房的管理。以下是顧客

32、預(yù)定，顧客登記，客戶管理和團(tuán)隊及協(xié)議單位管理這幾個方面的用例圖。如圖3.3,3.4,3.5所示：圖3.3顧客預(yù)定用例圖圖3.4顧客登記用例圖圖3.5團(tuán)隊/協(xié)議單位入住用例圖 房間狀態(tài)管理快捷酒店最核心的業(yè)務(wù)就是賣房間給客人，把房間當(dāng)做商品資源一樣賣出，因此房間也需要像商品資源一樣管理。并且房態(tài)圖的顯示必須做到實時快捷。如果房態(tài)圖有誤，則直接影響到銷售。由于酒店要做到對自己的所有房間狀態(tài)了如指掌，因此便誕生了房態(tài)圖這一模塊。如圖3.6。圖3.6房間狀態(tài)圖房間的狀態(tài)主要包括以下幾個狀態(tài)：(1)空凈：當(dāng)前沒人住，并且已經(jīng)打掃過房間。(2)空臟：當(dāng)前沒人住，但是沒有打掃過房間。(3)住凈

33、：當(dāng)前已經(jīng)有人入住，并且打掃過房間。(4)住臟：當(dāng)前已經(jīng)有人入住，并且沒有打掃過房間。，(5)維修：當(dāng)前房間正在維修，不允許入住。并且每一個狀態(tài)都有相應(yīng)的顏色顯示。每一個大方格代表一個房間，大方格內(nèi)的小方格則是顯示房間的其他一些信息。圖例如圖3.7圖3.7房間狀態(tài)圖圖例3.4.2 賬務(wù)及現(xiàn)付賬模塊設(shè)計 賬務(wù)模塊業(yè)務(wù)流程針對酒店管理系統(tǒng)，首先我們要做到的是賬務(wù)必須清楚明確，容不得一丁點差錯。這也是一個合格的管理系統(tǒng)所必備的。因此我們要確保每一條賬務(wù)都在歷史數(shù)據(jù)中有據(jù)可查，只要產(chǎn)生了賬務(wù)的登記單，就不能隨便刪除或者取消。賬務(wù)處理的具體時序圖如圖3.8所示：圖3.8顧客賬務(wù)處理時序圖3

34、.4.2.2 房務(wù)費管理用例描述房費管理包括房費信息錄入，錄入租用信息，及退還租賃物品。如圖3.9所示：圖3.9顧客房費管理用例圖 會員卡消費機(jī)制現(xiàn)代快捷酒店發(fā)展迅速，各個分店如雨后春筍般在城市中間涌現(xiàn)，因此，擁有一張會員卡，便可以在所有酒店消費已經(jīng)成了客戶的需要。會員卡一般與儲值卡相融合，但是根據(jù)國家的最新規(guī)定，會員卡的儲值額度已經(jīng)不能超過1000了。但是這樣也不影響會員卡所擁有的打折或者積分服務(wù)。會員卡消費流程如圖3.10所示：圖3.10會員消費示意圖3.4.3 報表管理模塊設(shè)計報表管理是以數(shù)據(jù)或者圖形形式統(tǒng)計和顯示當(dāng)前門店的運行情況。我們提供的快捷版管理系統(tǒng)包含了很多基本的

35、報表，比如近日到店入住報表，營業(yè)日報報表等，在實施的時候，也可根據(jù)酒店的要求增加酒店的自定義報表。通過報表顯示出想要得到的數(shù)據(jù)，并且清晰的呈現(xiàn)在操作人員眼里是十分重要的。我們以一天的營業(yè)日報為例，我們可以得到今天的各個部分的消費金額和結(jié)算金額。并且也支持報表打印功能。如圖3.11所示。圖3.11營業(yè)日報報表圖3.4.4 系統(tǒng)管理與維護(hù)模塊設(shè)計此模塊主要是系統(tǒng)管理員對酒店內(nèi)的員工分配角色和權(quán)限。酒店的信息管理，日志管理及與外部設(shè)備或者系統(tǒng)的接口管理等。 權(quán)限分配設(shè)計在這個快捷版的酒店系統(tǒng)中，權(quán)限是用權(quán)限字符串來表示和計算的。具體流程圖如下圖3.12所示。圖3.12權(quán)限查詢流程圖首先

36、，用戶登錄時查詢用戶表，看是否有此用戶存在。然后看此用戶的is_func_special字段是否為true。如果是的話則代表此用戶擁有獨立的權(quán)限，否則則查詢部門和角色表來獲取此用戶的權(quán)限。最后再更新use_auth_cache表中的權(quán)限字段。3.5 數(shù)據(jù)庫設(shè)計用e-r模型來創(chuàng)建和描述數(shù)據(jù)庫的邏輯結(jié)構(gòu),其基本思想是:描述實體與實體之間的關(guān)系,根據(jù)關(guān)系反映一個數(shù)據(jù)庫系統(tǒng)的設(shè)計和需求21。以下介紹表和視圖設(shè)計時，我將著重舉例介紹個張表是如何通過字段關(guān)聯(lián)在一起的。3.5.1 表和視圖的設(shè)計1預(yù)訂單和登記單表先介紹這個快捷版酒店管理系統(tǒng)中一個最大也是最重要的一張表，master_base表，這張表總共有

37、87個字段。他幾乎與數(shù)據(jù)庫中所有的表產(chǎn)生關(guān)聯(lián)。但是它并沒有外鍵，設(shè)計師如此設(shè)計也是為了系統(tǒng)的簡便性，并且在使用hibernate的時候可以自由控制數(shù)據(jù)的增刪改查。我們可以形容它為預(yù)定及等級單表。但是，它的字段絕不僅只有這些。下面我來分析一下它的幾個重要字段，看是如何與其他表產(chǎn)生聯(lián)系的。首先hotel_id和hotel_group_id是所有表都有的兩個字段，他們分別表示的是酒店代碼和酒店集團(tuán)代碼。當(dāng)id和master_id相同時，表示此人如果有同住人的話，則這個登記單時主同住人。其他*_id的功能也大都如此。rmtype和rmno是此登記單的房類與房型，屬于登記單信息。company_id在如

38、果是協(xié)議單位或者團(tuán)隊入住時才會設(shè)置值。這個字段算是與company_base表一個外鍵，但是并沒有設(shè)置成外鍵。rate_code是表示房價碼的字段，有關(guān)房價碼的表示code_ratecode。每一個房價碼都對應(yīng)一個房價。member_no則是此顧客的會員號，如果不是會員則為null。extra_flag是一連串的數(shù)字字符串，用來配置那些服務(wù)被開啟，并且開啟的等級是多少，比如電話計費，如果extra_flag的第三位是1表示僅僅可以打市話，是3表示可以打國內(nèi)長途，是5則表示可以打國際長途等。link_id則表示該登記單的聯(lián)房信息。如果兩張登記單的link_id相同，則表示兩個登記單是聯(lián)房關(guān)系。這

39、些還只是這張表字段一個大概介紹，其他字段也大都與上面介紹的相似用法。因此這張表集合了很多信息。如圖3.13所示。圖3.13登記單模型圖2顧客信息表主要涉及兩張表，master_guest和guest_base表。maste_guest是作為master_base和guest_base的中間表。master_guest中的id與master_base中的id是一一對應(yīng)的關(guān)系。master_guest中的profile_id則和guest_base中的id相互對應(yīng)。兩張表組合起來就能夠查到這個人的所有基本信息。master_guset中的vip字段表示這個住客的vip等級。為0則不是vip。如圖3

40、.14所示。圖3.14顧客管理模型圖3會員信息表與會員信息相關(guān)的兩張表分別是member_base和card_base。其中id與master_base中的guest_id與guest_base中的id相對應(yīng)。card_base中的id又與member_base中的inner_id對應(yīng)。兩張表一張儲存會員信息，一張儲存會員卡信息。如圖3.15所示。圖3.15會員管理模型圖4 房價信息表每一個房價都對應(yīng)一個房價碼，因此房價碼是整個房價系統(tǒng)的關(guān)鍵。code_ratecode主要儲存房價碼信息，而code_ratecode_detail則儲存房價信息。兩者用code也就是房價碼相互對應(yīng)。code_r

41、atecode_detail中的code是作為額外主鍵出現(xiàn)的。如圖3.16所示圖3.16房價信息模型圖5. 房間信息表room_no表中的id與room_sta表中的rmno_id是一一對應(yīng)的。room_no里面儲存房號信息，room_sta儲存房間狀態(tài)。room_no和room_sta表中都儲存了多天的同一房號的信息。結(jié)合這兩張表就可以確定該房間在某天的狀態(tài)。圖3.17房間信息模型圖3.5.2 存儲過程設(shè)計在java對數(shù)據(jù)庫進(jìn)行操作時，有時操作往往是非常復(fù)雜并且需要多次連接數(shù)據(jù)庫的操作。這時我們就需要用到存儲過程來幫我們完成對數(shù)據(jù)庫的操作。如果程序中出席那大量數(shù)據(jù)運算、業(yè)務(wù)邏輯處理需要多次連

42、接或者查詢數(shù)據(jù)庫，建議常采用存儲過程實現(xiàn), 這樣處理的性能高、處理速度快、并且調(diào)試方便22。因為存儲過程只涉及到數(shù)據(jù)庫的操作，因此比java連接數(shù)據(jù)庫得到數(shù)據(jù)后再操作快很多倍。并且也減輕了java端的負(fù)擔(dān)。而且存儲過程和數(shù)據(jù)庫的貼合明顯比java更加緊密。1.實現(xiàn)業(yè)務(wù)邏輯這些存儲過程主要是用來增加協(xié)議公司和團(tuán)隊，增加修改顧客的等級等等。如圖3.17所示。圖3.18公司級顧客信息修改存儲過程2使業(yè)務(wù)邏輯與java端分離，作為java端與數(shù)據(jù)庫端的中間層。（1）.酒店夜審：主要包括修改報表，計算房費，修改營業(yè)日期，計算房類資源等等。如圖3.18圖3.19酒店夜審存儲過程（2）.生成報表：通過這幾個

43、存儲過程，存儲過程中主要涉及賬目的計算。這幾個存儲過程負(fù)責(zé)生成報表信息。如圖3.20所示。圖3.20報表生成存儲過程3.6 其他功能模塊設(shè)計1.夜審管理主要負(fù)責(zé)當(dāng)日的關(guān)于賬務(wù)，房費，及報表審查等。并且修改房間占用資源狀態(tài)。修改營業(yè)日期等。如果不過夜審，軟件永遠(yuǎn)只停留在剛安裝的那一天，接下來也將無法使用。2.店長模塊管理層可以有許多前臺操作員沒有的權(quán)限，比如設(shè)置房類，房價。增刪改查協(xié)議單位和團(tuán)隊。夜審。用戶管理和傭金。第4章 快捷酒店管理系統(tǒng)的實現(xiàn)由于酒店系統(tǒng)是個十分龐大的系統(tǒng)，因此本章將只對用戶界面操作的部分及開發(fā)技術(shù)進(jìn)行詳細(xì)闡述。4.1 主要開發(fā)技術(shù)本系統(tǒng)涵蓋了快捷酒店業(yè)務(wù)的幾乎所有方面，因

44、此在頁面設(shè)計上也是比較復(fù)雜的。在頁面設(shè)計上我們采用了flex這種技術(shù)作為我們圖形界面開發(fā)的技術(shù)。開發(fā)工具使用的也是adobe公司提供的flashbuilder4.6作為開發(fā)工具。這是一種較為新穎的技術(shù)。以前開發(fā)網(wǎng)頁動畫都是用flash開發(fā)，但是這些只適合flash設(shè)計者。而adobe為了更多的編程人員和開發(fā)者能夠進(jìn)入到flash開發(fā)網(wǎng)頁的世界。他們設(shè)計了actionscript語言來完成這項工作。這是一門面向?qū)ο蟮哪_步腳步語言。同時也推出了與html十分相似的mxml，因此把他們兩個結(jié)合起來就是現(xiàn)在的flex。這項新的技術(shù)也使得程序員能夠更快的開發(fā)ria應(yīng)用。其強(qiáng)大的外觀設(shè)計也使得界面可以十分

45、絢麗。flex最大的優(yōu)點就是它也和java一樣是有虛擬機(jī)的，他的虛擬機(jī)是avm，內(nèi)存回收機(jī)制也和java相似。在框架上我們選用spring和hibernate。由hibernate構(gòu)建持久層，并且由spring構(gòu)建業(yè)務(wù)層23。本系統(tǒng)采用的數(shù)據(jù)庫是mysql數(shù)據(jù)庫，與其他數(shù)據(jù)庫相比。mysql數(shù)據(jù)庫具有以下主要特點： 一是，不限制同時訪問數(shù)據(jù)庫的用戶數(shù)量，允許通過多客戶端進(jìn)行訪問； 二是，可以保存最大超過50,000,000條記錄的數(shù)據(jù)； 三是，在目前市場上現(xiàn)有關(guān)系型數(shù)據(jù)庫系統(tǒng)產(chǎn)品中運行速度是最快的，并且開源； 四是，用戶權(quán)限設(shè)置比較簡單、有效。24 綜上所述，本系統(tǒng)開發(fā)時采用基于c/s架構(gòu)的w

46、eb應(yīng)用開發(fā)技術(shù)。以下是開發(fā)環(huán)境及工具的介紹。（1）系統(tǒng)結(jié)構(gòu)采用c/s架構(gòu)設(shè)計。支持多客戶端操作。（2）系統(tǒng)主要技術(shù)remoteobject，靈活的與java端進(jìn)行通信。（3）數(shù)據(jù)庫系統(tǒng)選擇成熟并且穩(wěn)定的開源數(shù)據(jù)庫mysql。（4）網(wǎng)絡(luò)服務(wù)器tomcat4.2 用戶界面實現(xiàn)用戶界面設(shè)計是一個系統(tǒng)的重要組成部分。大部分對系統(tǒng)的功能性需求也在用戶界面中得以體現(xiàn)。一個系統(tǒng)給人的第一印象就是界面，因此，界面的美觀與否直接決定了該系統(tǒng)能不能有好的市場。一個好的用戶界面應(yīng)該具備以下幾個特征（1）簡約自然原則。界面應(yīng)當(dāng)簡潔時尚。（2）可學(xué)習(xí)性原則。對新用戶不增加操作難度。（3）可理解性原則。用戶更好理解系統(tǒng)

47、。（4）一致性原則。交互模式應(yīng)當(dāng)與用戶的習(xí)慣保持一致。251.界面外觀設(shè)計由于本系統(tǒng)界面是采用flex開發(fā)，flex的一個重要特性就是對自定義組件的完美支持，由于flex皮膚和組件是以組合的方式結(jié)合在一起，因此在對界面進(jìn)行開發(fā)時，可以定義組件自己的皮膚，使得組件在外觀設(shè)計上更加美觀。2.界面功能設(shè)計由于flex是一個完全面向?qū)ο蟮恼Z言，他的語法也和java是差不多的。因此在功能設(shè)計上我們遵照面向?qū)ο蟮脑瓌t進(jìn)行開發(fā)。本系統(tǒng)最大的特點就是對flex中g(shù)roup類的加工，原先的flex設(shè)計的程序都是每次打開一個頁面都是全新的頁面，關(guān)閉頁面后則頁面交給avm虛擬機(jī)垃圾回收。如果垃圾回收不及時，則內(nèi)存的

48、占用率將會很高。針對flex的這個弊端，我們采用了加工group類的想法。用ocgroup來繼承g(shù)roup，并且重新其setvisible，也就是設(shè)置頁面可見的方法。當(dāng)頁面在主舞臺顯示時，則會觸發(fā)event.added_to_stage事件。然后調(diào)用opened函數(shù)。同樣，當(dāng)頁面從主舞臺消失時，則會觸發(fā)closed函數(shù)。本系統(tǒng)主要頁面都采用自定義的ocgroup來實現(xiàn)，因此，在界面每次打開時需要在opened函數(shù)中初始化界面的數(shù)據(jù)，在closed函數(shù)中又需要對界面中的數(shù)據(jù)進(jìn)行清空。進(jìn)過這樣的改善，程序運行起來更加迅速，在實際應(yīng)用中，內(nèi)存的占用率始終保持在150m左右便穩(wěn)定下來，原因就是使用了重

49、復(fù)的界面。4.2.1 登錄模塊的實現(xiàn)這個是簡單的登錄界面，輸入用戶名和密碼之后，點擊登錄即可。界面如圖4.1顯示圖4.1酒店登錄界面圖點擊“酒店注冊”后，可以如圖4.2界面中輸入酒店的注冊號：備注：由系統(tǒng)提供商提供酒店注冊號。圖4.2酒店注冊界面圖如點擊圖1-2中的切換酒店，則進(jìn)入如4.3圖：圖4.3選擇酒店頁面4.2.2 預(yù)定及登記模塊的實現(xiàn)預(yù)定及登記模塊是本系統(tǒng)中最為重要的一個模塊?？梢哉f其他所有模塊都為這兩個模塊服務(wù)的。由于這兩個模塊需要輸入的項目繁多，并且輸入的準(zhǔn)確性也難以預(yù)料，所以，在設(shè)計時我們將預(yù)定及登記分為許多個步驟，一個新建的單子只能按照步驟一步一步輸入才能完成，然后再保存。我

50、們把預(yù)訂單和登記單數(shù)據(jù)都放在一個純數(shù)據(jù)類的靜態(tài)變量里面，以方便各個頁面操作。代碼如下：bindablepublic static var masterclientdata:fmasterdto = null;預(yù)定單主要分為散客預(yù)定和團(tuán)隊預(yù)定。如圖4.4顯示圖4.4顧客預(yù)定界面第一步主要填寫房型，房類，日期等入住信息。第二部是填寫預(yù)訂人及聯(lián)系信息，第三部則是填寫有關(guān)銷售渠道之類的信息。由于有許多信息是以默認(rèn)值的形勢存在，因此只要填完少部分信息就可直接保存。下面將以散客入住為例說明系統(tǒng)的實現(xiàn)。散客一般指零星的客人，沒有參加旅行團(tuán)，并且不是協(xié)議公司的員工等得總稱.散客入住包括新建散客入住。預(yù)定轉(zhuǎn)入住

51、。重新入住。增加刪除同住人，打印登記單。預(yù)付款管理。聯(lián)房操作等。1.散客入住散客步入的界面如圖4.5所示：圖4.5步入散客顧客登錄界面操作步驟：1.新建入住登記單操作（1）散客步入打開步入散客窗口，出來第一步，其他步奏都灰色處理，因為是新建登記單，所以只能一步一步來。（2）選擇房型和房號，選擇完退房日期，然后進(jìn)入到第二步，住客信息。在此步驟中，由于本系統(tǒng)實現(xiàn)了與身份證讀卡器的接口。因此，基本信息不需要操作員填寫，只要把身份證放在身份證讀卡器掃描一下，就可出現(xiàn)顧客的其他信息。如需輸入聯(lián)系方式等其他信息則需要操作員手動輸入。第三步則是市場銷售，它主要填寫的是房價碼和房價及市場來源等。但是這些都只需

52、要操作員在幫助框中選擇，不需要親自填寫。（3）完成前面三步即可保存，保存時系統(tǒng)會檢驗數(shù)據(jù)的完整性與合法性。其實在每一步進(jìn)行完成到下一步時，數(shù)據(jù)也是會檢查的。只有完成了保存才能進(jìn)行后面的預(yù)收款和其他操作。當(dāng)數(shù)據(jù)檢查沒通過時會出現(xiàn)紅框提示。如圖4.6所示。圖4.6錯誤或為空提示框2.已有入住登記單操作此操作主要用來修改登記單信息及添加登記單的賬務(wù)信息的。只有已經(jīng)保存的登記單才能進(jìn)行第4,5,6步操作。還未保存的登記單只能進(jìn)行1-3步操作。這里將著重介紹第4,5,6步操作。如圖4.7所示圖4.7已有顧客修改或增加信息界面（1）修改登記單信息。與新建登記單不同的是，所有步驟都可以選擇。可以點擊最上排的

53、綠色功能組件來選擇要修改的步驟。在此就不多冗余。（2）新增預(yù)收款信息。這是第4步。當(dāng)?shù)怯泦我呀?jīng)保存之后，酒店就可以收取預(yù)收款了。如圖4.8顯示圖4.8增加預(yù)收款界面（3）增加其他信息。如圖4.9顯示圖4.9添加其它信息界面這里是許多功能集合的功能面板。例如點擊周期收費，則會出現(xiàn)如圖4.10顯示。圖4.10添加周期收費界面同樣的，這些也只能在已經(jīng)保存的登記單上操作?？梢愿鶕?jù)登記單狀態(tài)的不同來控制顯示的內(nèi)容。第5章 總結(jié)與展望5.1 總結(jié)通過這次開發(fā)快捷酒店管理系統(tǒng)，我深刻覺得酒店管理的erp軟件需要大力的推廣起來。每一個成功的公司都應(yīng)該需要一套自己的erp管理軟件。通過這次的開發(fā)，我承擔(dān)了部分需

54、求分析及設(shè)計內(nèi)容。也借鑒了其他的同類產(chǎn)品。達(dá)到了設(shè)計初的需求，也就是快捷，易用性。本系統(tǒng)已經(jīng)在德舒連鎖酒店試用。在開發(fā)過程中，始終遵循了面向?qū)ο蟮拈_發(fā)思想。采用了uml建模的方法。提高了設(shè)計和實現(xiàn)的效率。在后期的測試過程中。在內(nèi)存占用方面也表現(xiàn)出了良好的態(tài)勢。并且響應(yīng)速度也是非常迅速的。但是本系統(tǒng)仍然有很多不足之處。也有許多可以進(jìn)一步發(fā)展的方向。現(xiàn)在的時代是移動互聯(lián)網(wǎng)的時代，我們可以把本系統(tǒng)進(jìn)過進(jìn)一步開發(fā)，轉(zhuǎn)移到手機(jī)或者一切智能終端上面。給游客一個版本，并且給管理層一個可以圖形化查看報表的版本，介于此，我們可以展望一下下一步的工作。5.2 展望通過剛才的總結(jié)，我們可以想象到將來本產(chǎn)品的發(fā)展方向

55、。我們可以設(shè)計多個版本以供不同的用戶操作。同時可以移植到多個平臺上面。由于前臺開發(fā)時我們使用的是flex開發(fā)。actionscript語言和java語言一樣是基于虛擬機(jī)的。因此本系統(tǒng)也可以做成跨平臺的應(yīng)用。如我們前面提到的，可以設(shè)計一個ipad版本，只顯示報表和其他基本信息查詢的版本，用來給店長或者決策層使用。我們可以設(shè)計一個普通用戶版本，當(dāng)做app可以安裝到手機(jī)上，顧客可以通過本系統(tǒng)自主完成預(yù)定及入住。用flex開發(fā)還有一個好處就是可以無縫把客戶端變成網(wǎng)頁版本，這樣就更加靈活。致謝在此，首先我要感謝我的論文導(dǎo)師柴春雷，在論文完成期間給我的論文提了很多改進(jìn)意見。幫助我完成論文。也要感謝我的研究生德育導(dǎo)師朱小軍老師，在研究生期間給了我很大幫助。還要感謝實習(xí)期間的給我很大幫助的同事和領(lǐng)導(dǎo)，楊銘魁老師和張普軍。還有學(xué)院的各位教導(dǎo)過我的老師和領(lǐng)導(dǎo)。還有我親愛的同學(xué)。當(dāng)然最重要的是要感謝我的父母對我的養(yǎng)育之恩。特別要感謝初菁菁同學(xué)在論文和學(xué)習(xí)期間給我的莫大鼓勵和幫助。署名 魯俊于浙江大學(xué)軟件學(xué)院 2013.4.20參考文獻(xiàn) 1.姜麗娟, 基于java的酒店管理系統(tǒng)的設(shè)計與實現(xiàn). 電腦知識與技術(shù), 2011(27): p. 6569-6570. 2.eyster, j.j., ho