基于uml的餐館預(yù)約系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

《基于uml的餐館預(yù)約系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫。

1、基于UML的餐館預(yù)約系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)第一章餐館系統(tǒng)的業(yè)務(wù)建模1．1非正式的需求要開發(fā)的系統(tǒng)的意圖是，通過改進(jìn)為顧客預(yù)定和分配餐桌的過程，支持一家餐館的日常經(jīng)營(yíng)。1．1．1對(duì)計(jì)算機(jī)化系統(tǒng)的需要原始手工系統(tǒng)速度慢，而且，預(yù)約登記單很快就變得難以理解。這可能導(dǎo)致經(jīng)營(yíng)上的問題，例如，實(shí)際上有空餐桌而由于這個(gè)預(yù)約單不是很明顯，會(huì)妨礙顧客進(jìn)行預(yù)約；沒有備份系統(tǒng)，如果一張預(yù)約單被毀壞了，餐桌就沒有了那個(gè)晚上有什么預(yù)約的記錄。由于這些以及其他原因，該餐館意欲開發(fā)一個(gè)預(yù)約單的自動(dòng)化版本。新系統(tǒng)應(yīng)該和現(xiàn)有的預(yù)約單顯示同樣的信息，并且有大致相同的格式，使餐館員工易于轉(zhuǎn)換到

2、新系統(tǒng)。當(dāng)記錄了新的預(yù)約時(shí)，或者對(duì)已有的預(yù)約進(jìn)行修改時(shí)，應(yīng)該立即更新顯示，使餐館員工在工作時(shí)總能使用可獲得的最新信息。系統(tǒng)必須易于記錄餐館營(yíng)業(yè)時(shí)發(fā)生的有意義的事情，例如顧客的到來。系統(tǒng)的操作應(yīng)當(dāng)盡可能是直接操作屏幕上顯示的數(shù)據(jù)。例如，可以簡(jiǎn)單地將預(yù)約拖動(dòng)到屏幕上一個(gè)適當(dāng)?shù)奈恢靡愿淖円粋€(gè)預(yù)約的時(shí)間或者分配的餐桌。1．2用例建模用例視圖應(yīng)該是客戶、最終用戶、領(lǐng)域?qū)＜?、測(cè)試人員和任何其他涉及系統(tǒng)的人員，不需要詳細(xì)了解系統(tǒng)結(jié)構(gòu)和實(shí)現(xiàn)就容易理解的。用例視圖不描述軟件系統(tǒng)的組織或結(jié)構(gòu)，它的作用是給設(shè)計(jì)者施加約束，設(shè)計(jì)者必須設(shè)計(jì)出一個(gè)能夠提供用例視圖中指定的功能的

3、結(jié)構(gòu)。1．2．1用例通過考慮在系統(tǒng)實(shí)現(xiàn)后餐館員工能夠用它來做什么，草擬出一組初步的用例。這些用例所支持的主要任務(wù)：（1）記錄一個(gè)新的預(yù)約信息（“記錄預(yù)約”）（2）取消一個(gè)預(yù)約（“取消預(yù)約”）（3）記錄一位顧客的到來（“記錄到來”）（4）將一位顧客從一張餐桌移到另一張餐桌（“調(diào)換餐桌”）1．2．2參與者在餐館預(yù)約系統(tǒng)中，所提出的用例可以分成兩組。第一組由與維護(hù)提前預(yù)約信息有關(guān)的用例組成。顧客將聯(lián)系餐館提前預(yù)約或取消提前預(yù)約，一般地，接待員將接到這些電話并更新預(yù)約系統(tǒng)中存儲(chǔ)的信息，因此，我們能夠確定一個(gè)相應(yīng)用例關(guān)聯(lián)的參與者。在第二組中有許多任務(wù)需要在餐館

4、營(yíng)業(yè)時(shí)執(zhí)行，包括記錄顧客的到來，以及為了適應(yīng)不可預(yù)料的經(jīng)營(yíng)需要將一行用餐者從一個(gè)餐桌移到另一個(gè)餐桌。這些工作譬如說可能是一個(gè)侍者領(lǐng)班的責(zé)任，因此我們能夠標(biāo)識(shí)另一個(gè)與這些用例關(guān)聯(lián)的參與者。1．2．3用例圖餐館預(yù)約系統(tǒng)的初始用例圖如圖1．1所示，其中包括了上面確定的參與者與用例。1．3描述用例用例描述了系統(tǒng)和它的用戶之間在一定層次上的完整的交互。例如，一個(gè)打電話給餐館進(jìn)行預(yù)約的顧客，會(huì)和餐館的一位將在系統(tǒng)中記錄預(yù)約的店員講話，該店員需要充當(dāng)一個(gè)接待員（即使這并不是他們正式職位的描述），并且以某種方式和系統(tǒng)交互。這種情況下，該店員被認(rèn)為是接待員參與者的一個(gè)

5、實(shí)例，發(fā)生在接待員和系統(tǒng)之間的交互是用例的一個(gè)實(shí)例。1．3．1事件路徑用例描述必須定義在執(zhí)行用例時(shí)用戶和系統(tǒng)之間的交互。在“記錄預(yù)約”用例中，基本事件路徑將描述這樣的情況：一位顧客打電話進(jìn)行預(yù)約，在要求的日期和時(shí)間有一張合適的餐桌是空閑的，接待員輸入顧客的姓名和電話號(hào)碼并記錄預(yù)約。這樣的事件路徑，如下所示，能夠以稍微結(jié)構(gòu)化的方式表示，以強(qiáng)調(diào)用戶的動(dòng)作和系統(tǒng)響應(yīng)之間的交互：記錄預(yù)約：基本事件路徑（1）接待員輸入要預(yù)約的日期；（1）系統(tǒng)顯示該日的預(yù)約；（2）有一張合適的餐桌可以使用：接待員輸入顧客的姓名和電話號(hào)碼、預(yù)約的時(shí)間、用餐人數(shù)和餐桌號(hào)；（3）系統(tǒng)

6、記錄并顯示該預(yù)約。如果在顧客要求的日期和時(shí)間沒有可用的餐桌，上面描述的基本事件路徑就不能完成。在這種情況下會(huì)發(fā)生什么可以通過一個(gè)可選事件路徑描述，如下所示：記錄預(yù)約——沒有可用的餐桌：可選事件路徑（1）接待員輸入要求預(yù)約的日期；（2）系統(tǒng)顯示該日的預(yù)約；（3）沒有合適的餐桌可以使用，用例終止?？蛇x事件路徑描述的情況，可以作為營(yíng)業(yè)的一個(gè)正常部分出現(xiàn)，它們并沒有指出產(chǎn)生了誤解，或者發(fā)生了錯(cuò)誤。在另外一些情況下，也許因?yàn)橐粋€(gè)錯(cuò)誤或用戶的疏忽而不可能完成基本事件路徑，這些情況則由例外事件路徑描述。如果接待員錯(cuò)誤地試圖將一個(gè)預(yù)約分配到過小而不能滿足就餐者人數(shù)的

7、餐桌就座時(shí)，這可能就要作為一個(gè)例外事件路徑描述了。記錄預(yù)約——餐桌過?。豪馐录窂剑?）接待員輸入要求預(yù)約的日期；（2）系統(tǒng)顯示該日的預(yù)約；（3）接待員輸入顧客的姓名和電話，預(yù)約的時(shí)間，用餐人數(shù)和餐桌號(hào)；（4）輸入的預(yù)約用餐人數(shù)多于餐桌能容納的人數(shù)，于是系統(tǒng)發(fā)出一個(gè)警告信息詢問用戶是否想要繼續(xù)預(yù)約；（5）如果回答“否”，用例將不進(jìn)行預(yù)約而終止；（6）如果回答“是”，預(yù)約將被輸入，并附有一個(gè)警告標(biāo)志。1．3．2用戶界面原型用例描述的重點(diǎn)是定義系統(tǒng)和用戶之間交互的總體結(jié)構(gòu)，而包含用戶界面的細(xì)節(jié)會(huì)使之不清晰。并且，用戶界面應(yīng)該被設(shè)計(jì)得協(xié)調(diào)一致并便于使用，

8、而這只有合理地考慮了各式各樣的用戶任務(wù)才能做到。1．4組織用例模型記錄一個(gè)預(yù)約后要處理的重要事件是顧客到達(dá)餐