UML酒店管理系統(tǒng)動態(tài)圖

--------《UML系統(tǒng)分析與設計》實訓報告系別:計算機科學與工程班級: 網絡0801姓名: XＸX學號: 2指導老師： XＸX日期：201012月２4日酒店預訂系統(tǒng)小組成員及分工XXX 餐桌信息設置時序圖、協(xié)作圖,訂餐時序圖、協(xié)作圖,訂單狀態(tài)圖XXX 組件圖,用例圖及事件流文檔XXＸ 類圖、權限設置時序圖、權限設置協(xié)作圖、權限設置活動圖教師評語一、 課題詳述題目四:酒店預訂系統(tǒng)基本業(yè)務流程:顧客預約：記錄,取消，修改,查詢和顯示顧客到達：有預約顧客和無預約顧客相分離；用餐顧客結帳：同時刷新餐桌和預約信息顯示:顯示當前桌子的狀態(tài)完成以下模塊:（１)預約模塊:顯示當天所有預約，同時桌子根據當前時間顯示當前狀態(tài):如果是當天預約則顯示在預約狀態(tài)欄中,,時間以及餐桌如果是當天預約則刷新預約狀態(tài)欄:餐桌號，預約日期，時間查詢預約狀態(tài)（2）到達模塊另一種是無預約的到達故在預約模塊中添加到達的功能就可以立即找空桌子用餐在到達操作中還要刷新當前桌子狀態(tài),由預約或空閑狀態(tài)轉為用餐狀態(tài)（3）結帳模塊進行結帳操作,,態(tài)工作內容及要求根據三人的分工，請在一周內完成下列工作內容:進一步細化需求分析的內容，識別出系統(tǒng)的參與者,并完成用例圖；將用例圖中的每個用例都寫成相應的事件流文檔;進一步使用活動圖來描述每個用例，為后續(xù)的系統(tǒng)設計做好準備;按照系統(tǒng)的功能分析,從用例的描述中提取出系統(tǒng)的對象類和界面類,類圖;分析類圖中的實體類和實體類之間的關系，畫出數據庫的邏輯模型圖(包含實體類，且注明角色和階元。對數據庫的邏輯模型進行優(yōu)化,取消多對多的聯(lián)系,計;（按功能分別描述。提交結果及要求請?zhí)峤挥美龍D（包括事件流文檔、類圖、活動圖、交互作用圖?？蛇x提交：狀態(tài)機圖、系統(tǒng)部署圖完成規(guī)定格式的實驗報告（紙質系統(tǒng)建模的成果（各類圖和相關文檔，電子文檔。二、 需求分析酒店管理系統(tǒng)要能完成以下功能：預定餐桌:首先檢查客戶的訂餐信息，然后根據訂餐信息選擇相應級別的餐桌或包間。顧客結賬：顯示當前正在用餐的桌子信息,從中選中需要結帳的桌子,進行結帳操作，結帳完成后,將桌子置為空閑狀態(tài),若當天還有不同時間預約此桌子的則置該桌為預約狀態(tài)。員工能夠對信息進行管理。根據要求可將系統(tǒng)分為七個模塊客戶申請注冊登錄模塊作人員遞交申請,工作人員根據系統(tǒng)情況，回復客戶。系統(tǒng)管理員登陸模塊系統(tǒng)管理員工作需要登陸系統(tǒng),才能夠進行操作，系統(tǒng)中的各項數據都不允許外人隨便查看和更改,所以設置登陸模塊是必須的。顧客到達模塊,預約,由預約或空閑狀態(tài)轉為用餐狀態(tài)４顧客結賬模塊顯示當前正在用餐的桌子信息,從中選中需要結帳的桌子,進行結帳操作，結帳完成后，將桌子置為空閑狀態(tài),若當天還有不同時間預約此桌子的則置該桌為預約狀態(tài)。餐桌信息管理模塊工作人員可以對公司的餐桌進行管理。工作人員可以查詢公司的餐桌情況,包括就餐情況，就餐歷史,餐桌狀況。客戶信息管理模塊在酒店就餐過的會員，工作人員需要記錄下就餐情況,以便再次預定就餐時可以查詢。新注冊的客戶，工作人員需要添加新會員進系統(tǒng)中。會員權限管理模塊管理員查詢會員的權限，寫入新的權限。三、 靜態(tài)結構建各類之間的關系類不是單獨一個模塊,各個類之間是存在聯(lián)系。酒店預訂系統(tǒng)各類之間的聯(lián)系如圖：可以設置餐桌的狀態(tài)信息。會員可以瀏覽餐桌信息和申請訂單,申請訂單成功后就可以通過網上支付系統(tǒng)支付定金。四、 動態(tài)結構建模用例圖1 業(yè)務處理系統(tǒng)(圖１）客戶登陸系統(tǒng)進入個人信息管理,如果不是會員,先注冊成為會員,然后登陸系統(tǒng)選擇查詢餐桌相關信息，最后下訂單。2

圖1 業(yè)務處理系統(tǒng)組件圖

圖2 系統(tǒng)管理員的系統(tǒng)管理該圖是系統(tǒng)的各個組件圖,由主界面、個人信息管理、權限設置、餐桌信息設置、餐桌信息、個人訂單管理?；顒訄D會員查看餐桌信息，在登陸狀態(tài)下請求訂餐,并選擇底單、支付方式，在管理員確定后，訂餐成功。時序圖1 權限設置時序圖餐桌信息設置時序圖管理員可以查看、設置餐桌的狀態(tài)信息。訂餐時序圖會員可以通過登陸訂餐系統(tǒng)，查詢餐桌信息,選擇餐桌，并進行網上支付定金，最終生成訂單。然后管理員修改相關餐桌狀態(tài)信息。管理員可以打開權限窗口，查詢所有會員或某個會員,寫入新的權限后，保存，完成設置。協(xié)作圖1 權限設置協(xié)作圖2 餐桌信息設置協(xié)作圖狀態(tài)圖１ 餐桌信息狀態(tài)圖管理員和會員都可以查詢餐桌狀態(tài)信息,會員可以預訂、退訂,際情況修改餐桌信息。2 訂單狀態(tài)圖訂單狀態(tài)圖顯示,系統(tǒng)記錄餐桌信息、餐桌信息及付款信息，會員可以修改訂單，請求通過后可以生成訂單?；顒訄D１權限設置活動圖五、 事件流文檔用例“注冊”的描述前置條件在客戶網上注冊成為會員之前，必須要先進入該酒店的網上酒店預訂系統(tǒng)。后置條件如果“注冊”用例成功,客戶就成為了改酒店的會員。擴充點無１．４事件流1．４.1基流用戶進入系統(tǒng)是用例訂約注冊的開始,填寫申請表,填寫正確提交后,工作人員根據申請表,回復用戶申請表是否通過。用戶可以通過電話和前臺，詢問工作人員自己的申請,工作人員根據系統(tǒng)記錄，處理申請。管理員根據用戶填寫的申請表，給予該用戶會員的資格,并回復該用戶已經注冊成功可以登陸。1.4.2 分支流無1.4.無用例“登陸”的描述１前置條件在客戶網上登陸之前,必須要先成為酒店的網上會員，并登陸進入該酒店的網上酒店預訂系統(tǒng)。后置條件如果“登陸”用例成功，客戶可以填寫申請表，進行網上訂餐。擴充點無事件流２.4.1會員成功登陸進入系統(tǒng)后,查詢餐桌信息,填寫訂餐信息并提交,等待管理員處理申請。如果該餐桌狀態(tài)良好并且閑置，執(zhí)行分支流s－1:同意申請。如果該餐桌不能使用，執(zhí)行分支流s-2:拒絕申請。如果該餐桌已有人預定，執(zhí)行分支流s－2:拒絕申請。如果用戶申請完成,則用例結束推出。2.４.2分支流同意申請管理人員根據用戶的申請,根據系統(tǒng)中餐桌的情況,同意用戶的申請，把申請結果返回給用戶,用例結束。駁回申請工作人員根據用戶的申請,根據系統(tǒng)中餐桌的情況，駁回用戶的申請,例重新開始。2．4.3替代流無３用例“選擇訂單”的描述３．1前置條件在用例個選擇訂單之前,用戶必須成為該酒店的網絡會員并成功登陸系統(tǒng)。后置條件如果這個用例成功，則用戶可以處理個人的訂單管理。擴充點無事件流3．4.1基流,管理員處理申請。如果該餐桌空置并無預訂,執(zhí)行分支流ｓ-1:同意申請。如果該餐桌處于就餐狀態(tài),執(zhí)行分支流s-2：駁回申請。如果用戶選擇訂單完成,則用例結束推出。3.4.2分支流ｓ-1 同意申請工作人員根據餐桌的空置并且無預訂狀況，同意用戶的申請,把申請結果返回給用戶，用例結束。s-2駁回申請工作人員根據該餐桌處于就餐狀態(tài),駁回用戶的申請，用例重新開始。３.4.3替代流無4 ４.１前置條件在用例個人信息管理之前,用戶必須成為該酒店的網絡會員,并登陸訂餐系統(tǒng)。后置條件如果這個用例成功，則用戶可以處理個人信息管理。擴充點無４.4事件流4.４.1基流會員進入個人信息管理系統(tǒng)后,存。4.4.2分支流無４.4.3替代流無用例“個人訂單管理”的描述前置條件在用例個人訂單管理之前,用戶必須成為該酒店的網絡會員。后置條件如果這個用例成功,則用戶可以處理個人的訂單管理。擴充點無事件流4.４．1基流會員進入個人訂單管理系統(tǒng)后,可以查詢個人餐桌信息及繳費情況,也可以申請修改訂單,等待系統(tǒng)管理員處理申請。如果管理員根據實際情況確定能夠修改，執(zhí)行分支流s-1:同意申請。s如果用戶申請修改訂單完成，則用例結束推出。４.４.2分支流ｓ-１同意申請工作人員根據用戶的申請的要求和現實的狀況，同意用戶的申請,把申請結果返回給用戶，用例結束。s-2 駁回申請工作人員根據用戶的申請的要求和現實的狀況，駁回用戶的申請,用例重新開始。４．4.3替代流無５．1前置條件在用例餐桌管理之前，管理員必須先登錄訂餐管理系統(tǒng)。后置條件在管理員用例餐桌信息管理后,管理員可以更改、預訂、退訂餐桌的狀態(tài)信息。無５.4事件流５.4.1管理員成功登陸進入系統(tǒng)后,查詢餐桌狀態(tài)或預訂情況,可以進行餐桌狀態(tài)的修改。如果該餐桌從空置狀態(tài)進入就餐狀態(tài),執(zhí)行分支流s-1:就餐狀態(tài)。如果該餐桌從就餐狀態(tài)進入空置狀態(tài),執(zhí)行分支流s-2:空置狀態(tài)。如果客戶預訂該餐桌,執(zhí)行分支流s－3：預訂狀態(tài)。如果客戶退訂該餐桌，執(zhí)行分支流s-2：空置狀態(tài)。如果餐桌管理完成，則用例結束推出。５.4．2分支流s-1就餐狀態(tài)客戶