快捷酒店管理系統(tǒng)設計與前端實現(xiàn)_第1頁
快捷酒店管理系統(tǒng)設計與前端實現(xiàn)_第2頁
快捷酒店管理系統(tǒng)設計與前端實現(xiàn)_第3頁
快捷酒店管理系統(tǒng)設計與前端實現(xiàn)_第4頁
快捷酒店管理系統(tǒng)設計與前端實現(xiàn)_第5頁
已閱讀5頁,還剩42頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、. . . . 快捷酒店管理系統(tǒng)設計與前端實現(xiàn)41 / 47摘要目前,我國快捷型酒店發(fā)展十分迅速,但是相對于酒店的快速擴展,酒店管理軟件的更新卻不是如此與時,快捷酒店相對于的操作應該是十分簡單明了,但是傳統(tǒng)酒店管理系統(tǒng)操作十分復雜,導致操作員需要大量時間學習如何操作。本文主要介紹了如何針對快捷酒店的需求,通過Flex編寫的前臺程序,和后臺迅速交互。達到使客戶認為操作簡單并且容易上手。介紹Flex關于RIA的開發(fā)流程與Flex用作客戶端編程所帶來的好處。分析整個酒店管理系統(tǒng)的架構,分析各個功能模塊的基本數(shù)據(jù)結構,接口,功能流程等。最后對系統(tǒng)的特點與不足之處進行總結。關鍵詞:Flex,RIA,快捷

2、酒店,模塊功能,系統(tǒng)架構AbstractAt present, 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

3、 staffs do not need spend too 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

4、 flex Programming as Client. 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,

5、inn hotel, functional model, system frame目錄摘要iAbstractii圖目錄III第1章 緒論11.1 課題背景11.2 發(fā)展與現(xiàn)狀11.3 研究的目標和容2第2章 相關技術和方法32.1 RIA介紹32.2 Flex技術簡介32.3 RemoteObject介紹42.4 Spring框架簡介42.5 Hibernate框架簡介5第3章 系統(tǒng)的需求分析與概要設計73.1 系統(tǒng)的需求分析73.2 系統(tǒng)的總體設計73.3 模塊設計83.3.1 功能介紹83.4 主要功能模塊103.4.1 入住管理模塊設計113.4.2 賬務與現(xiàn)付賬模塊設計153.4.3

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

7、序圖16圖3.9顧客房費管理用例圖16圖3.10會員消費示意圖17圖3.11營業(yè)日報報表圖18圖3.12權限查詢流程圖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顧客預定界面31圖4.5步入散客顧客登錄界面32圖4.6錯誤或為空提示框33圖4.7已有顧客修改或增加信息界面34圖4.8增加預收款界面35圖4.9添加其它

8、信息界面36圖4.10添加周期收費界面37第1章 緒論目前,我國快捷連鎖酒店企業(yè)還沒有真正屬于自己的適合自己發(fā)展需要的快捷酒店的管理軟件,大的連鎖酒店如:如家,漢庭用的都是自己酒店部開發(fā)的酒店管理系統(tǒng)。其他快捷酒店管理系統(tǒng)則主要來自各種星級酒店的管理系統(tǒng)。與自己的酒店業(yè)務辦理有一些出入。因此我實習所在的公司,準備開發(fā)出一套專門針對快捷酒店快速反應與符合其業(yè)務需求的管理軟件。不僅滿足酒店的管理需求,也能充分讓住客體驗到快捷酒店的方便與實用性。1.1 課題背景本文的課題主要來自作者的工程實踐,以綠云軟件的酒店管理系統(tǒng)的開發(fā)為背景,利用公司已開發(fā)的星級酒店管理系統(tǒng),來設計一個針對快捷酒店的管理系統(tǒng)。

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

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

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

12、和容本文以某快捷酒店管理系統(tǒng)項目為例,對快捷酒店管理系統(tǒng)項目研發(fā)過程中的需求分析,架構設計,產品測試與性能分析進行了實質性的研究。研究的目標是:結合快捷酒店管理系統(tǒng)項目的特點和開發(fā)過程,分析其設計模式與架構。分析各個功能模塊的基本數(shù)據(jù)結構,接口,功能流程等。探討如何設計出適用于快捷酒店管理系統(tǒng)項目的系統(tǒng)架構與對此系統(tǒng)完成后進行的系統(tǒng)性能進行詳細分析。分析包括客戶端程序在長時間運行時對操作系統(tǒng)資源占用和高并發(fā)操作時是否影響系統(tǒng)性能與穩(wěn)定性。第2章 相關技術和方法2.1 RIA介紹RIA(Rich Internet Applications)富互聯(lián)網應用,傳統(tǒng)的英特網應用程序都是把大量的對數(shù)據(jù)的處

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

14、IA引擎接收瀏覽器發(fā)出的請求后,調用本地的業(yè)務邏輯處理組件(一般是網頁腳本語言)異步轉發(fā)該請求到服務器;服務器給予應答后,RIA引擎再利用自身的客戶端框架程序處理數(shù)據(jù)和和樣式特效對頁面進行包裝,反饋給瀏覽器顯示5。2.2 Flex技術簡介Flex是由Adobe公司發(fā)布的R IA應用程序框架,它提供了豐富的用戶界面組件, 其開發(fā)模型由ActionScrip t3 (兼容ECMAScrip t這個國際標準的面向對象的腳本語言) ,MXML 模型描述語言(基于XML,實現(xiàn)標簽化的定義方式,可用于可視化的編輯) ,以與其他的擴展類庫組成的6。它與Adobe發(fā)布的另一款產品Flash是一個模式。Flex

15、和Flash一樣都是生成.swf文件運行。但相對于flash動畫有多幀,F(xiàn)lex制作出來的界面只有兩幀。第一幀是預加載,第二幀就得到了我們想要的頁面。ActionScript 3.0 是Adobe發(fā)布的一種面向對象編程語言,它提供MXML 所不具備的對程序流程的控制和對象操作等功能。Flex 編譯器和調試器與虛擬機AVM幫助把MXML 與ActionScript 3.0 源代碼編譯成能夠運行在Flash Player 中的二進制文件7。這點也是Flex和Flash相似之處,它們都運行在Flash Player當中。但是Flex與Flash也是有明顯差別的,F(xiàn)lex提供了一種完全面向對象的語言A

16、ctionscript并且是跨平臺的。它打破了Flash只能由專業(yè)的美工設計師來完成的局面。普通程序員也可以通過Flex完成絢麗的界面效果。Flex 和基于Strut s ,Spring , Hibernate 的傳統(tǒng)J2EE 而言,可以通過AMF 這種模式網關進行集成Flex 。從而在不影響原先應用的情況下,RIA 對表示層的功能和顯示靈活性進行了豐富增強8。2.3 RemoteObject介紹Flex 可以利用3 種方法來實現(xiàn)與服務器端交換數(shù)據(jù)的功能, 分別是使用 Service 組件、使用WebService 組件和使用RemoteObject 組件9。在Flex作為客戶端開發(fā)程序時,我

17、們采用的是RemoteObject組件的方式來實現(xiàn)與java端通信。我們使用BlazeDS來完成java端與Flex端的通信。Flex與java使用RemoteObject是異步通信的。也就是說,F(xiàn)lex端發(fā)完請求之后不需要等待服務器端的響應,可以做別的事情。RemoteObject 組件和服務器之間傳遞信息采用Action Message Format(AMF) 編碼的二進制格式,RemoteObject 組件可以直接將AMF 編碼的信息轉換成Flex可以識別的Object對象10。這樣方便了前臺對數(shù)據(jù)的處理。并且使用RemoteObject比其他兩種方式占用的存更少。2.4 Spring框

18、架簡介Spring是一個輕量級的Java開源框架,它遵循了面向對象的設計模式。并且把設計模式運用到實際開發(fā)與應用中。Spring 框架是一種在J2EE 的基礎上構建起來的一個輕量級面向對象的框架實現(xiàn), 它是一個分層的應用程序開發(fā)框架, 而不是單獨某一層例如Web 層開發(fā)框架11。相對于J2EE 而言,Spring具有維護容易、分層清楚、速度快、代碼少、支持ORM 對象關系映射和AOP面向切面編程的概念等優(yōu)點12。Spring所展現(xiàn)出來的兩種編程思想,一種是依賴注入(DI),一種是面向方面編程(AOP)。依賴注入概念上來說是程序不應該依賴于具體,而是應該依賴于抽象。簡單來說是在運行期由Sprin

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

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

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

22、就是把關系型數(shù)據(jù)庫轉換成為面向對象語言所能讀懂的對象。Hibernate的核心接口如下圖所示。其中Transaction接口是處理控制事務的。它主要在程序中合適的地方定義事務的開始和結束。對應于數(shù)據(jù)庫操作的事務。Query和Criteria接口是數(shù)據(jù)庫的查詢。Configration類主要負責配置和啟動Hibernate。創(chuàng)建SessionFactory實例來維護數(shù)據(jù)庫連接池17。圖2.1Hibernate結構模式圖由于Hibernate只對JDBC 做了輕量級封裝, 應用程序可以使用Hibernate API對數(shù)據(jù)庫進行操作, 也可以直接不使用Hibernate提供的方便,使用JDBC 完成

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

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

25、e serverA5A4JDBCconfig圖3.1系統(tǒng)總體設計圖A1:客戶端讀取config中的URL地址,連接到應用服務器端。A2:客戶端以RemoteObject的方式與應用服務器交互。A3:接受到的數(shù)據(jù)通過Java端程序處理和控制。A4:Java端讀取JDBC配置文件。準備連接數(shù)據(jù)庫A5:java端與數(shù)據(jù)庫端進行通信。完成操作并且返回數(shù)據(jù)。由于前端使用Flex制作界面,F(xiàn)lex和Java有很多種的通信方式。提到通信,我們有兩方面的問題,一是選擇通信協(xié)議,二是選擇數(shù)據(jù)協(xié)議。通信協(xié)議如TCP,UDP, 等。數(shù)據(jù)協(xié)議則是規(guī)定數(shù)據(jù)交換的格式,如Json,XML,amf3等。在這個項目中,我們使

26、用Adobe提供的BlazeDS這個開源框架來實現(xiàn)java與Flex之間的通信。它已經為我們提供了java封裝AMF3格式的方法。然后我們應用Hibernate和Spring這兩個開源框架。把整個業(yè)務應用劃分為三層,分別為表現(xiàn)層(UI),業(yè)務邏輯層(BLL),和數(shù)據(jù)訪問層(DAL)。這也完全體現(xiàn)了面向對象開發(fā)的“高聚,低耦合”的思想。一個軟件組件僅僅是一個使我們可以關聯(lián)不同的責任的抽象的設計實體20。綜上所述,系統(tǒng)采用的架構設計是典型的MVC的思想。把客戶端作為視圖層。把Java端不包括與數(shù)據(jù)庫交互的部分作為控制層。把Java端與數(shù)據(jù)庫交互的模塊作為模型層。這種分層的架構設計,不僅降低了系統(tǒng)的

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

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

29、3.3.1.6房價與傭金體系管理此房價模塊主要管理鐘點房與全日房的房價,每一個房價都有與之對應的房價碼,各種客戶入住都有與之對應的房價碼,才能找到與之對應的房價。傭金管理則是如果顧客是通過第三方平臺預定并入住,則需要計算傭金給第三方平臺。3.3.1.7預定和接待管理此模塊是酒店管理系統(tǒng)中比較重要的模塊,負責處理酒店的預定和入住的所有事物,此模塊幾乎與所有模塊都產生交互,此模塊直接決定了此系統(tǒng)的用戶體驗。3.3.1.8客房中心管理此模塊主要負責管理每個房間當時的客房狀態(tài)。管理哪些房間可用,哪些不可用。并且負責房間是否打掃的狀態(tài)等。3.3.1.9前臺收銀和應收賬管理此功能主要負責前臺收銀和應收賬務

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

31、為:店長系統(tǒng),系統(tǒng)維護,夜審系統(tǒng)和報表系統(tǒng)等。下圖顯示了入住管理和系統(tǒng)管理的主要流程,其中起到橋梁作用的便是夜審。如圖3.2所示。R:預定狀態(tài)的登記單。I:在住狀態(tài)的登記單。S:掛賬狀態(tài)的登記單。指入住完酒店后,但并不直接付款,通過記帳的形勢方便以后一起計算。O:已經結賬的登記單。X:已經被取消的預定單。N:應到未到的預訂單。W:wait狀態(tài)的登記單。D:刪除了的登記單。圖3.2酒店業(yè)務流程圖3.4.1 入住管理模塊設計入住管理模塊主要涉與客人的預定入住,房間的狀態(tài)顯示與顧客的資料管理 3.4.1.1 前臺入住用例描述入住管理主要包括顧客的預定,登記,客房管理,房價,換房與排房的管理。以下是顧

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

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

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

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

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

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

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

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

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

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

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

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

44、設計上我們采用了Flex這種技術作為我們圖形界面開發(fā)的技術。開發(fā)工具使用的也是Adobe公司提供的FlashBuilder4.6作為開發(fā)工具。這是一種較為新穎的技術。以前開發(fā)網頁動畫都是用Flash開發(fā),但是這些只適合Flash設計者。而Adobe為了更多的編程人員和開發(fā)者能夠進入到Flash開發(fā)網頁的世界。他們設計了ActionScript語言來完成這項工作。這是一門面向對象的腳步腳步語言。同時也推出了與html十分相似的mxml,因此把他們兩個結合起來就是現(xiàn)在的Flex。這項新的技術也使得程序員能夠更快的開發(fā)RIA應用。其強大的外觀設計也使得界面可以十分絢麗。Flex最大的優(yōu)點就是它也和J

45、ava一樣是有虛擬機的,他的虛擬機是AVM,存回收機制也和java相似。在框架上我們選用Spring和Hibernate。由Hibernate構建持久層,并且由Spring構建業(yè)務層23。本系統(tǒng)采用的數(shù)據(jù)庫是mysql數(shù)據(jù)庫,與其他數(shù)據(jù)庫相比。MySQL數(shù)據(jù)庫具有以下主要特點: 一是,不限制同時訪問數(shù)據(jù)庫的用戶數(shù)量,允許通過多客戶端進行訪問; 二是,可以保存最大超過50,000,000條記錄的數(shù)據(jù); 三是,在目前市場上現(xiàn)有關系型數(shù)據(jù)庫系統(tǒng)產品中運行速度是最快的,并且開源; 四是,用戶權限設置比較簡單、有效。24綜上所述,本系統(tǒng)開發(fā)時采用基于C/S架構的Web應用開發(fā)技術。以下是開發(fā)環(huán)境與工具的

46、介紹。(1)系統(tǒng)結構采用C/S架構設計。支持多客戶端操作。(2)系統(tǒng)主要技術RemoteObject,靈活的與Java端進行通信。(3)數(shù)據(jù)庫系統(tǒng)選擇成熟并且穩(wěn)定的開源數(shù)據(jù)庫MYSQL。(4)網絡服務器Tomcat4.2 用戶界面實現(xiàn)用戶界面設計是一個系統(tǒng)的重要組成部分。大部分對系統(tǒng)的功能性需求也在用戶界面中得以體現(xiàn)。一個系統(tǒng)給人的第一印象就是界面,因此,界面的美觀與否直接決定了該系統(tǒng)能不能有好的市場。一個好的用戶界面應該具備以下幾個特征(1)簡約自然原則。界面應當簡潔時尚。(2)可學習性原則。對新用戶不增加操作難度。(3)可理解性原則。用戶更好理解系統(tǒng)。(4)一致性原則。交互模式應當與用戶的

47、習慣保持一致。251.界面外觀設計由于本系統(tǒng)界面是采用Flex開發(fā),F(xiàn)lex的一個重要特性就是對自定義組件的完美支持,由于Flex皮膚和組件是以組合的方式結合在一起,因此在對界面進行開發(fā)時,可以定義組件自己的皮膚,使得組件在外觀設計上更加美觀。2.界面功能設計由于Flex是一個完全面向對象的語言,他的語法也和Java是差不多的。因此在功能設計上我們遵照面向對象的原則進行開發(fā)。本系統(tǒng)最大的特點就是對Flex中Group類的加工,原先的Flex設計的程序都是每次打開一個頁面都是全新的頁面,關閉頁面后則頁面交給AVM虛擬機垃圾回收。如果垃圾回收不與時,則存的占用率將會很高。針對Flex的這個弊端,我

48、們采用了加工Group類的想法。用OCGroup來繼承Group,并且重新其setvisible,也就是設置頁面可見的方法。當頁面在主舞臺顯示時,則會觸發(fā)Event.ADDED_TO_STAGE事件。然后調用opened函數(shù)。同樣,當頁面從主舞臺消失時,則會觸發(fā)closed函數(shù)。本系統(tǒng)主要頁面都采用自定義的OCGroup來實現(xiàn),因此,在界面每次打開時需要在opened函數(shù)中初始化界面的數(shù)據(jù),在closed函數(shù)中又需要對界面中的數(shù)據(jù)進行清空。進過這樣的改善,程序運行起來更加迅速,在實際應用中,存的占用率始終保持在150M左右便穩(wěn)定下來,原因就是使用了重復的界面。4.2.1 登錄模塊的實現(xiàn)這個是簡

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

50、態(tài)變量里面,以方便各個頁面操作。代碼如下:Bindablepublicstaticvar masterClientData:FMasterDto = null;預定單主要分為散客預定和團隊預定。如圖4.4顯示圖4.4顧客預定界面第一步主要填寫房型,房類,日期等入住信息。第二部是填寫預訂人與聯(lián)系信息,第三部則是填寫有關銷售渠道之類的信息。由于有許多信息是以默認值的形勢存在,因此只要填完少部分信息就可直接保存。下面將以散客入住為例說明系統(tǒng)的實現(xiàn)。散客一般指零星的客人,沒有參加旅行團,并且不是協(xié)議公司的員工等得總稱.散客入住包括新建散客入住。預定轉入住。重新入住。增加刪除同住人,打印登記單。預付款管

51、理。聯(lián)房操作等。1.散客入住散客步入的界面如圖4.5所示:圖4.5步入散客顧客登錄界面操作步驟:1.新建入住登記單操作(1)散客步入打開步入散客窗口,出來第一步,其他步奏都灰色處理,因為是新建登記單,所以只能一步一步來。(2)選擇房型和房號,選擇完退房日期,然后進入到第二步,住客信息。在此步驟中,由于本系統(tǒng)實現(xiàn)了與讀卡器的接口。因此,基本信息不需要操作員填寫,只要把放在讀卡器掃描一下,就可出現(xiàn)顧客的其他信息。如需輸入聯(lián)系方式等其他信息則需要操作員手動輸入。第三步則是市場銷售,它主要填寫的是房價碼和房價與市場來源等。但是這些都只需要操作員在幫助框中選擇,不需要親自填寫。(3)完成前面三步即可保存

52、,保存時系統(tǒng)會檢驗數(shù)據(jù)的完整性與合法性。其實在每一步進行完成到下一步時,數(shù)據(jù)也是會檢查的。只有完成了保存才能進行后面的預收款和其他操作。當數(shù)據(jù)檢查沒通過時會出現(xiàn)紅框提示。如圖4.6所示。圖4.6錯誤或為空提示框2.已有入住登記單操作此操作主要用來修改登記單信息與添加登記單的賬務信息的。只有已經保存的登記單才能進行第4,5,6步操作。還未保存的登記單只能進行1-3步操作。這里將著重介紹第4,5,6步操作。如圖4.7所示圖4.7已有顧客修改或增加信息界面(1)修改登記單信息。與新建登記單不同的是,所有步驟都可以選擇??梢渣c擊最上排的綠色功能組件來選擇要修改的步驟。在此就不多冗余。(2)新增預收款信

53、息。這是第4步。當?shù)怯泦我呀洷4嬷螅频昃涂梢允杖☆A收款了。如圖4.8顯示圖4.8增加預收款界面(3)增加其他信息。如圖4.9顯示圖4.9添加其它信息界面這里是許多功能集合的功能面板。例如點擊周期收費,則會出現(xiàn)如圖4.10顯示。圖4.10添加周期收費界面同樣的,這些也只能在已經保存的登記單上操作??梢愿鶕?jù)登記單狀態(tài)的不同來控制顯示的容。第5章 總結與展望5.1 總結通過這次開發(fā)快捷酒店管理系統(tǒng),我深刻覺得酒店管理的ERP軟件需要大力的推廣起來。每一個成功的公司都應該需要一套自己的ERP管理軟件。通過這次的開發(fā),我承擔了部分需求分析與設計容。也借鑒了其他的同類產品。達到了設計初的需求,也就是快

54、捷,易用性。本系統(tǒng)已經在德舒連鎖酒店試用。在開發(fā)過程中,始終遵循了面向對象的開發(fā)思想。采用了UML建模的方法。提高了設計和實現(xiàn)的效率。在后期的測試過程中。在存占用方面也表現(xiàn)出了良好的態(tài)勢。并且響應速度也是非常迅速的。但是本系統(tǒng)仍然有很多不足之處。也有許多可以進一步發(fā)展的方向?,F(xiàn)在的時代是移動互聯(lián)網的時代,我們可以把本系統(tǒng)進過進一步開發(fā),轉移到手機或者一切智能終端上面。給游客一個版本,并且給管理層一個可以圖形化查看報表的版本,介于此,我們可以展望一下下一步的工作。5.2 展望通過剛才的總結,我們可以想象到將來本產品的發(fā)展方向。我們可以設計多個版本以供不同的用戶操作。同時可以移植到多個平臺上面。由

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論