1、餐飲點菜管理系統分析與設計一：餐飲行業點菜管理系統設計的需求分析傳統的餐飲服務流程中，人工點菜、下單、催菜、結賬等環節不僅需要許多人力，還會在執行過程中消耗掉不少時間， 降低餐廳的效率， 容易使顧客產生不滿的同時，也增加了餐廳的成本。 如何在生活節奏日益加快及競爭越來越激烈的今天，提高餐廳效率，從而提升顧客滿意度、降低成本，是眾多餐飲行業想要克服的難題。盡管我國現階段餐飲業的發展無論是在行業規模、 設施質量上，還是在經營觀念、管理水平上，都已經取得了長足的進步。據統計，餐飲行業的年增長率比其它行業 高了十個百分點以上，被稱為中國的黃金產業。擁有著巨大的消費市場。餐飲行業也是一個古老的行業， 最

2、初出現的是手工餐飲， 在這種手工作坊式的 方法中，存在著很多弊端。比如，人工計算賬單容易出現差錯，收銀過程中的漏單、 偷錢現象普遍發生，客人的消費單據也難以保存和查詢，更無法對營業數據進行統 計分析方便于以后業務的決策。電子商務的模式異軍崛起， 為餐飲業的發展帶來了機遇和挑戰。 很多餐飲企業， 尤其是大型的餐飲企業，依托于先進的信息工具，不斷的提高自身的市場應變能力與生存能力。在規模比較大的餐飲企業， 其優勢已經比較明顯和突出。無論是顧客的預定、接待、點菜、上菜的效率，還是在生意繁忙的時候，電子化的管理方式都能夠極大的提高餐廳的運行效率。 同時在條碼劃菜、 收銀、營業額 統計等各方面也起到了積

3、極的作用。除了餐廳的電子化管理，人員的管理也可以通 過電子商務來實現。查詢營業收入統計、員工業績統計、人均消費額等。電子商務的運動對餐飲業的經營在業務管理方面和人員管理方面都起到輔助決策作用。二：餐飲行業點菜管理系統設計的可行性分析分析2.1 技術可行性隨著國餐飲量的日益增長的需求，一個智能化的點菜系統的市場空間廣闊。構建這個系統所需要的軟硬件環境并不復雜，就其技術構成而言，還是一個數據庫應用類的應用系統，其基本操作還是對數據庫的增加、刪除、查找等，無 非是多了一個客戶端和服務器的交互。所以技術上不存在太大的問題2.2 經濟可行性對于現在比較大的企業而言，一個智能化的點菜系統一般都是由幾個終端

4、和后臺服務器組成。 這種技術架構很成熟， 但是弊端是功能比較單一， 只能作為點餐使用。增加了系統成本， 造成了資源的浪費。 而且此系統只能夠由餐廳服務員使用。而本智能點菜系統， 可以由服務員幫助來餐館的顧客使用，也可以由已經注冊的用戶自己訂菜，用戶群體更大，無形中節約了資源。對于餐廳而言， 也擴展了服務群體的圍。2.3 開發環境可行性本系統的開發環境如下，這些開發環境全部免費：Visual C+ 6.0SQL sever 2000( 暫定于這個，可能用其他的數據庫)三：用例的詳細描述：（ 1）管理系統 參與者：系統管理員 前置條件：正確登錄，對系統進行管理。 異常：輸入數據格式不正確或者不能正

5、確登錄。 后置條件：返回系統的主界面或者登錄界面。（ 2）點菜 參與者：顧客，服務員 前置條件：注冊后的用戶可以通過登錄，顯示點菜界面。或者餐廳服務員通過登錄，顯示點菜界面。 異常：顧客未能正常登陸，或者未注冊。 后置條件：記錄菜品被點次數，生成菜單。（ 3）記錄菜品被點次數 參與者：經理、廚師 前置條件：登錄正確，顧客已經點菜，并且交易成功。 異常：系統記錄出錯。后置條件：返回系統界面。（ 4）退訂 參與者：顧客、服務員 前置條件：顧客登錄，正常點菜，并且在計時系統允許前退訂。 異常：顧客不能正常登錄，或者未注冊，或者已經登錄但退訂的菜未點，或者已經過了計時系統的計時。 后置條件：生成菜單。

6、（ 5）生成菜單 參與者：廚師 前置條件：用戶登錄，并且成功的進行了點菜、退訂。異常：廚師沒有正常登陸，或者未注冊，或者沒有菜品被點。后置條件：返回系統界面。（ 6）評價 參與者：酒店經理、顧客、廚師 前置條件：用戶正確登錄系統。 異常：用戶不能登錄系統，或者用戶未注冊。 后置條件：返回系統界面。（ 7）查看 參與者：顧客、服務員 前置條件：顧客已經登錄系統并且點菜、退訂成功，或者餐廳的顧客通過服務員幫助已經成功點菜、退訂。 異常：顧客未能正常登陸，或未注冊，或顧客沒有點菜。 后置條件：計算價格。（ 8）結賬系統 參與者：顧客 前置條件：顧客登錄系統成功，并且已經正常點菜。 異常：顧客不能正常

7、登錄， 或未注冊，或未點餐，或金額不足。 后置條件：計算價格，銷售統計系統（ 9）銷售統計系統 參與者：經理、時間 前置條件：顧客登錄系統，點菜完成并完成結賬業務。 異常：用戶不能正常登陸、或者未注冊。 后置條件：返回銷售系統主界面。（ 10）查臺 前置條件：服務員能夠正常登錄系統。 異常：服務員不能正常登陸，或者未注冊。 后置條件：返回登錄界面。（ 11）開臺 參與者：服務員 前置條件：服務員能夠正常登錄系統， 查臺。 異常：服務員不能正常登陸，或者未注冊，或已沒有座位。 后置條件：返回系統主菜單。（ 12）轉臺 參與者：服務員 前置條件：服務員正常登陸系統，并且已經為顧客開臺。 異常：服務

8、員不能正常登陸系統，或未注冊，或已沒有可轉的座位。 后置條件：返回系統主菜單。（ 13）并臺 參與者：服務員 前置條件：服務員正常登錄系統，并且已經為顧客開臺。 異常：服務員不能正常登錄系統， 或未注冊，或已沒有可并臺的座位。 后置條件：返回系統主菜單。四：系統模塊框圖一個軟件的好壞最重要的是取決于軟件的架構， 軟件架構設計的好， 可以在后期很容易的對系統進行修改與增補， 減少需求變更所帶來的成本。 軟件架構沒有固定的設計 要求，面向對象的軟件架構設計的一般標準是松耦合，緊聚。松耦合能夠降低系統模 塊間的依賴性聯系，在一部分受到影響的時候其它部分能正常工作。緊聚指的是模塊 部各部分之間的聯系很

9、緊，能夠把一個模塊當成一個整體對待。這個原理同樣適 用于基于手機的應用軟件。在本系統中，客戶端和服務器端就是一個松耦合， 它們之間僅僅是通過數據交換產生聯系。 系統總體的功能模塊圖如圖 4-1 所示。圖 4-1 系統功能模塊框圖五：類圖的設計在類圖中，人員管理系統屬于餐飲平臺的另一個系統， 暫且不屬于本文討論的 圍，可以使用原有的人員管理系統，以便節省成本，與原公司框架融合，也可重 新開發新的人員系統，便于更好的與本系統相適應。訂餐管理系統的類圖如圖 5-1 所示。圖 5-1 訂餐管理系統類圖六：數據庫的設計create table hjbjh(bkj int,bb int)七：系統各功能模塊

10、的設計上面進行了系統總體功能模塊的設計， 下面針對系統的各子功能模塊分別進行 詳細的設計，并且給出系統的主要功能相應的順序圖、活動圖。順序圖是消息在對 象模型部傳遞的流程。活動圖是系統在執行某一個用例時具體的步驟，它主要表 現的是系統的動作，從活動途中可以看到用例的完成過程，以及中間涉及到的參與 者，可以說是用例圖的一中細化，加深對本系統的理解，找出本系統的部的流程。7.1 個人信息管理模塊個人信息管理包括了三個部分，個人信息查詢 /修改、用戶注銷、用戶狀態查詢。 個人信息管理模塊圖如圖 7-1 所示。個人信息主要是用戶注冊時所提供的信息，其中 包括用戶名，密碼，用戶的地址，等信息。個人信息管

11、理的主要目的是提供用 戶進行資料修改的接口。個人信息管理的功能包括修改密碼，修改手機，修改 地址，增加或刪除地址，提升 VIP 等級。第二個是用戶狀態的查詢，包括用戶 VIP 等級，是否處于訂餐狀態。最后一個是用戶注銷。圖 7-1 個人信息管理模塊圖7.2 訂單管理模塊訂單管理：餐飲店可以通過推薦訂單向用戶推薦餐廳的特色訂單。 用戶也可以通過菜品信息查詢進行訂單的自定義， 并對自定義訂單進行管理。 比如刪除訂單，修改訂單。 訂單信息查詢是查看現在正在訂購的訂單狀態。歷史訂單查詢主要是記錄未付賬的訂單 信息。訂購與退訂模塊主要是用來生成訂單。訂餐管理模塊圖如圖 7-2 所示。圖 7-2 訂單管理

12、模塊圖在訂單管理中， 訂購與退訂的管理是整個業務的核心功能。 我們通過順序圖對訂購和退訂的流程做詳細的分析。服務員登錄系統，可以查看餐館的餐桌信息。 當有顧客進入到餐廳， 服務 員可以接待并且將顧客引領到餐桌前為顧客點菜，由于在該軟件中可以查看菜譜，服務員可以很容易的報出菜名以便顧客選取。這時候可以適當的配合紙質菜譜，在顧客需要時交給顧客自己查閱。服務員點菜的順序圖如圖7-3 所示。圖 7-3服務員點菜順序圖7.3 餐桌管理模塊餐桌管理：當顧客進入餐廳時， 服務員通過查臺可以獲知餐廳的餐桌使用情況。當顧客走進餐廳后，可以通過開臺功能為顧客下訂單。下單后，可以通過轉臺功能為要求換座位的顧客轉臺， 也可以通過并臺功能將已下單的兩組顧客合并到一桌子，顧客用餐后，通過結臺功能更新餐桌的狀態。 餐桌管理模塊圖如圖 7-4 所示。圖 7-4餐桌管理模塊圖7.4 菜品管理模塊菜品管理：管理員通過菜品管理可以對系統進行初始化， 將菜品添加到數據庫，菜品管理其實就是菜品的增加、刪除、修改、查詢的操作。菜品管理模塊圖如圖 7-5 所示。圖 7-5 菜品管理模塊圖7.5 其它模塊推薦訂單管理： 管理員可以定制餐廳