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

1、<p>　　基于UML的餐館預(yù)約系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)</p><p>　　第一章 餐館系統(tǒng)的業(yè)務(wù)建模</p><p>　　1．1 非正式的需求</p><p>　　要開發(fā)的系統(tǒng)的意圖是，通過(guò)改進(jìn)為顧客預(yù)定和分配餐桌的過(guò)程，支持一家餐館的日常經(jīng)營(yíng)。</p><p>　　1．1．1 對(duì)計(jì)算機(jī)化系統(tǒng)的需要</p><p&g

2、t;　　原始手工系統(tǒng)速度慢，而且，預(yù)約登記單很快就變得難以理解。這可能導(dǎo)致經(jīng)營(yíng)上的問(wèn)題，例如，實(shí)際上有空餐桌而由于這個(gè)預(yù)約單不是很明顯，會(huì)妨礙顧客進(jìn)行預(yù)約；沒有備份系統(tǒng)，如果一張預(yù)約單被毀壞了，餐桌就沒有了那個(gè)晚上有什么預(yù)約的記錄。</p><p>　　由于這些以及其他原因，該餐館意欲開發(fā)一個(gè)預(yù)約單的自動(dòng)化版本。新系統(tǒng)應(yīng)該和現(xiàn)有的預(yù)約單顯示同樣的信息，并且有大致相同的格式，使餐館員工易于轉(zhuǎn)換到新系統(tǒng)。當(dāng)記錄了新的

3、預(yù)約時(shí)，或者對(duì)已有的預(yù)約進(jìn)行修改時(shí)，應(yīng)該立即更新顯示，使餐館員工在工作時(shí)總能使用可獲得的最新信息。</p><p>　　系統(tǒng)必須易于記錄餐館營(yíng)業(yè)時(shí)發(fā)生的有意義的事情，例如顧客的到來(lái)。系統(tǒng)的操作應(yīng)當(dāng)盡可能是直接操作屏幕上顯示的數(shù)據(jù)。例如，可以簡(jiǎn)單地將預(yù)約拖動(dòng)到屏幕上一個(gè)適當(dāng)?shù)奈恢靡愿淖円粋€(gè)預(yù)約的時(shí)間或者分配的餐桌。</p><p><b>　　1．2 用例建模</b>&

4、lt;/p><p>　　用例視圖應(yīng)該是客戶、最終用戶、領(lǐng)域?qū)＜摇y(cè)試人員和任何其他涉及系統(tǒng)的人員，不需要詳細(xì)了解系統(tǒng)結(jié)構(gòu)和實(shí)現(xiàn)就容易理解的。用例視圖不描述軟件系統(tǒng)的組織或結(jié)構(gòu)，它的作用是給設(shè)計(jì)者施加約束，設(shè)計(jì)者必須設(shè)計(jì)出一個(gè)能夠提供用例視圖中指定的功能的結(jié)構(gòu)。</p><p><b>　　1．2．1 用例</b></p><p>　　通過(guò)考慮在系統(tǒng)

5、實(shí)現(xiàn)后餐館員工能夠用它來(lái)做什么，草擬出一組初步的用例。這些用例所支持的主要任務(wù)：</p><p>　　記錄一個(gè)新的預(yù)約信息（“記錄預(yù)約”）</p><p>　　取消一個(gè)預(yù)約（“取消預(yù)約”）</p><p>　　記錄一位顧客的到來(lái)（“記錄到來(lái)”）</p><p>　　將一位顧客從一張餐桌移到另一張餐桌（“調(diào)換餐桌”）</p>&l

6、t;p><b>　　1．2．2 參與者</b></p><p>　　在餐館預(yù)約系統(tǒng)中，所提出的用例可以分成兩組。第一組由與維護(hù)提前預(yù)約信息有關(guān)的用例組成。顧客將聯(lián)系餐館提前預(yù)約或取消提前預(yù)約，一般地，接待員將接到這些電話并更新預(yù)約系統(tǒng)中存儲(chǔ)的信息，因此，我們能夠確定一個(gè)相應(yīng)用例關(guān)聯(lián)的參與者。</p><p>　　在第二組中有許多任務(wù)需要在餐館營(yíng)業(yè)時(shí)執(zhí)行，包括記錄

7、顧客的到來(lái)，以及為了適應(yīng)不可預(yù)料的經(jīng)營(yíng)需要將一行用餐者從一個(gè)餐桌移到另一個(gè)餐桌。這些工作譬如說(shuō)可能是一個(gè)侍者領(lǐng)班的責(zé)任，因此我們能夠標(biāo)識(shí)另一個(gè)與這些用例關(guān)聯(lián)的參與者。</p><p><b>　　1．2．3 用例圖</b></p><p>　　餐館預(yù)約系統(tǒng)的初始用例圖如圖1．1所示，其中包括了上面確定的參與者與用例。</p><p><b

8、>　　1．3 描述用例</b></p><p>　　用例描述了系統(tǒng)和它的用戶之間在一定層次上的完整的交互。例如，一個(gè)打電話給餐館進(jìn)行預(yù)約的顧客，會(huì)和餐館的一位將在系統(tǒng)中記錄預(yù)約的店員講話，該店員需要充當(dāng)一個(gè)接待員（即使這并不是他們正式職位的描述），并且以某種方式和系統(tǒng)交互。這種情況下，該店員被認(rèn)為是接待員參與者的一個(gè)實(shí)例，發(fā)生在接待員和系統(tǒng)之間的交互是用例的一個(gè)實(shí)例。</p>&l

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

10、;/p><p>　　記錄預(yù)約：基本事件路徑</p><p>　　接待員輸入要預(yù)約的日期；</p><p>　　系統(tǒng)顯示該日的預(yù)約；</p><p>　　有一張合適的餐桌可以使用：接待員輸入顧客的姓名和電話號(hào)碼、預(yù)約的時(shí)間、用餐人數(shù)和餐桌號(hào)；</p><p>　　系統(tǒng)記錄并顯示該預(yù)約。</p><p>

11、;　　如果在顧客要求的日期和時(shí)間沒有可用的餐桌，上面描述的基本事件路徑就不能完成。在這種情況下會(huì)發(fā)生什么可以通過(guò)一個(gè)可選事件路徑描述，如下所示：</p><p>　　記錄預(yù)約——沒有可用的餐桌：可選事件路徑</p><p>　　接待員輸入要求預(yù)約的日期；</p><p>　　系統(tǒng)顯示該日的預(yù)約；</p><p>　　沒有合適的餐桌可以使用，用

12、例終止。</p><p>　　可選事件路徑描述的情況，可以作為營(yíng)業(yè)的一個(gè)正常部分出現(xiàn)，它們并沒有指出產(chǎn)生了誤解，或者發(fā)生了錯(cuò)誤。在另外一些情況下，也許因?yàn)橐粋€(gè)錯(cuò)誤或用戶的疏忽而不可能完成基本事件路徑，這些情況則由例外事件路徑描述。</p><p>　　如果接待員錯(cuò)誤地試圖將一個(gè)預(yù)約分配到過(guò)小而不能滿足就餐者人數(shù)的餐桌就座時(shí)，這可能就要作為一個(gè)例外事件路徑描述了。</p>&l

13、t;p>　　記錄預(yù)約——餐桌過(guò)?。豪馐录窂?lt;/p><p>　　接待員輸入要求預(yù)約的日期；</p><p>　　系統(tǒng)顯示該日的預(yù)約；</p><p>　　接待員輸入顧客的姓名和電話，預(yù)約的時(shí)間，用餐人數(shù)和餐桌號(hào)；</p><p>　　輸入的預(yù)約用餐人數(shù)多于餐桌能容納的人數(shù)，于是系統(tǒng)發(fā)出一個(gè)警告信息詢問(wèn)用戶是否想要繼續(xù)預(yù)約；</

14、p><p>　　如果回答“否”，用例將不進(jìn)行預(yù)約而終止；</p><p>　　如果回答“是”，預(yù)約將被輸入，并附有一個(gè)警告標(biāo)志。</p><p>　　1．3．2 用戶界面原型</p><p>　　用例描述的重點(diǎn)是定義系統(tǒng)和用戶之間交互的總體結(jié)構(gòu)，而包含用戶界面的細(xì)節(jié)會(huì)使之不清晰。并且，用戶界面應(yīng)該被設(shè)計(jì)得協(xié)調(diào)一致并便于使用，而這只有合理地考慮了各

15、式各樣的用戶任務(wù)才能做到。</p><p>　　1．4 組織用例模型</p><p>　　記錄一個(gè)預(yù)約后要處理的重要事件是顧客到達(dá)餐館，該用例的基本事件路徑如下：</p><p>　　記錄到達(dá)：基本事件路徑</p><p>　　侍者領(lǐng)班輸入當(dāng)前日期；</p><p>　　系統(tǒng)顯示當(dāng)天的預(yù)約；</p>&l

16、t;p>　　侍者領(lǐng)班確認(rèn)一個(gè)選定的預(yù)約已經(jīng)到達(dá)；</p><p>　　系統(tǒng)對(duì)此進(jìn)行記錄并更新顯示器，將顧客標(biāo)記為已到達(dá)。</p><p>　　在這個(gè)用例中，如果系統(tǒng)記錄中沒有到達(dá)顧客的預(yù)約，可能發(fā)生一個(gè)可選事件路徑：如果有適當(dāng)?shù)牟妥朗强臻e的，則創(chuàng)建一個(gè)未經(jīng)預(yù)約的登記。</p><p>　　記錄到達(dá)——沒有提前預(yù)定：可選事件路徑</p><p

17、>　　侍者領(lǐng)班輸入當(dāng)前日期；</p><p>　　系統(tǒng)顯示當(dāng)天的預(yù)約；</p><p>　　系統(tǒng)中沒有記錄該顧客的預(yù)約，所以侍者領(lǐng)班輸入預(yù)約時(shí)間、用餐人數(shù)和餐桌號(hào)，創(chuàng)建一個(gè)未預(yù)約登記；</p><p>　　系統(tǒng)記錄并顯示新預(yù)約。</p><p>　　1．4．1 用例包含</p><p>　　考慮餐館經(jīng)理可能試圖計(jì)

18、算一個(gè)特定的晚上要雇傭多少個(gè)侍者，那么，簡(jiǎn)單地看看當(dāng)天的預(yù)約可能是估計(jì)餐館大約會(huì)有多繁忙的一個(gè)好辦法。這就需要定義一個(gè)相應(yīng)于顯示給定一天預(yù)約任務(wù)的新用例。這個(gè)用例能夠被餐館的任何工作人員執(zhí)行，因而任何參與者都可以在下面對(duì)基本事件路徑的描述中被提及。</p><p>　　顯示預(yù)約：基本事件路徑</p><p><b>　　用戶輸入一個(gè)日期；</b></p>

19、<p>　　系統(tǒng)顯示當(dāng)日的預(yù)約。</p><p>　　這個(gè)新用例和已經(jīng)描述的用例之間的關(guān)系可以這樣來(lái)描述：只要在執(zhí)行其他用例之一時(shí)就包含“顯示預(yù)約”用例中的交互。</p><p>　　記錄預(yù)約：基本事件路徑（修改）</p><p>　　接待員執(zhí)行 “顯示預(yù)約”用例；</p><p>　　接待員輸入顧客姓名和電話號(hào)碼、預(yù)定的時(shí)間、用

20、餐人數(shù)以及預(yù)留的餐桌；</p><p>　　系統(tǒng)記錄和顯示新預(yù)約。</p><p>　　一個(gè)用例和它所包含的其他用例之間的關(guān)系在用例圖中用一個(gè)連接兩個(gè)用例的虛線箭頭表示，稱為依賴。圖1．2表示了“記錄預(yù)約”和“顯示預(yù)約”之間的“包含”依賴性。</p><p>　　1．4．2 參與者泛化</p><p>　　參與者之間泛化的含義是，特化的參與者

21、可以參與和更一般的參與者關(guān)聯(lián)的所有用例。圖1．3中描述了一個(gè)新參與者，它表示餐館所有員工可以共享的能力，稱為“員工”已有的參與者通過(guò)泛化與新參與者相關(guān)，表示它們被看作是“員工”的特殊情況，定義了只能由一個(gè)員工子集共享的附加特性。</p><p>　　圖1．3指定了接待員和侍者領(lǐng)班都可以執(zhí)行“顯示預(yù)約”用例。另外，可以指派給特化的參與者更多的責(zé)任，圖1．3指定只有接待員才能夠記錄預(yù)約，而只有侍者領(lǐng)班才可以記錄到達(dá)。

22、</p><p>　　1．4．3 用例擴(kuò)展</p><p>　　“記錄到達(dá)”用例的可選事件路徑規(guī)定，如果系統(tǒng)沒有記錄一個(gè)顧客的預(yù)約，侍者領(lǐng)班將通過(guò)創(chuàng)建一個(gè)未預(yù)約登記來(lái)表示他們?cè)诓宛^用餐的事實(shí)。但是，將記錄未預(yù)約登記表示為單獨(dú)一個(gè)用例可能更好一些，因?yàn)槲搭A(yù)約登記將會(huì)為那些從不提前進(jìn)行預(yù)約的顧客創(chuàng)建。</p><p>　　“記錄未預(yù)約顧客”用例的基本事件路徑將會(huì)被某個(gè)沒

23、有預(yù)約就來(lái)用餐的人觸發(fā)。它的結(jié)構(gòu)非常類似于“記錄預(yù)約”用例，只是在記錄的細(xì)節(jié)上不同。</p><p>　　記錄未預(yù)約顧客：基本事件路徑</p><p>　　侍者領(lǐng)班執(zhí)行“顯示預(yù)約”用例；</p><p>　　侍者領(lǐng)班輸入時(shí)間、用餐人數(shù)和分配給顧客的餐桌；</p><p>　　系統(tǒng)記錄并顯示新預(yù)約。</p><p>　　

24、“記錄到達(dá)”用例的可選事件路徑和這個(gè)新用例的描述之間有相當(dāng)多的重疊?！坝涗浳搭A(yù)約顧客”用例只是在“記錄到達(dá)”的某些情況下被執(zhí)行，也就是該顧客沒有記錄的預(yù)約，但有一個(gè)適當(dāng)?shù)牟妥揽臻e，并且顧客還想在餐館用餐時(shí)才被執(zhí)行。</p><p>　　“記錄到達(dá)”用例可以被“記錄未預(yù)約顧客”用例擴(kuò)展，來(lái)描述這種情況。如圖1．4</p><p>　　1．5 完成用例模型</p><p&g

25、t;　　取消預(yù)約的基本事件路徑可以如下指定。</p><p>　　取消預(yù)約：基本事件路徑</p><p>　　接待員選擇要求的預(yù)約；</p><p><b>　　接待員取消該預(yù)約；</b></p><p>　　系統(tǒng)詢問(wèn)接待員確認(rèn)取消；</p><p>　　接待員回答“是”，系統(tǒng)記錄取消并更新顯示。

26、</p><p>　　“調(diào)換餐桌”用例的基本事件路徑也可以獨(dú)立于用戶界面的細(xì)節(jié)進(jìn)行定義如下。</p><p>　　調(diào)換餐桌：基本事件路徑</p><p>　　侍者領(lǐng)班選擇需要的預(yù)約；</p><p>　　侍者領(lǐng)班改變?cè)擃A(yù)約的餐桌分配；</p><p>　　系統(tǒng)記錄改變并更新顯示。</p><p>

27、;　　這個(gè)用例可以通過(guò)一個(gè)菜單選項(xiàng)調(diào)用，由用戶在一個(gè)對(duì)話框中填寫新的餐桌號(hào)，或者通過(guò)將預(yù)約矩形拖到它的新位置完成調(diào)換餐桌。</p><p>　　1．5．1 一個(gè)用例模型完成</p><p>　　圖1．5描述的是一個(gè)完整的用例圖，它是總結(jié)了上面對(duì)餐館預(yù)約系統(tǒng)的第一次迭代的用例討論。</p><p><b>　　1．6 領(lǐng)域建模</b></p

28、><p>　　在餐館預(yù)約系統(tǒng)中，關(guān)鍵的業(yè)務(wù)需求是記錄顧客已經(jīng)預(yù)定的事實(shí)，所以領(lǐng)域建?？梢詮臉?biāo)識(shí)表示預(yù)定和顧客這兩個(gè)類開始。系統(tǒng)必須記錄每個(gè)進(jìn)行預(yù)定的顧客的姓名和電話號(hào)碼，比較合理的是將這些作為顧客類的屬性建模。</p><p>　　預(yù)定的日期和時(shí)間是很直接的屬性，可以作為屬性建模。系統(tǒng)還必須記錄分配給一個(gè)預(yù)定的餐桌，這可以通過(guò)將餐桌號(hào)作為預(yù)定的另一個(gè)屬性來(lái)記錄，還有一個(gè)選擇是將每張餐桌作為一個(gè)

29、自主對(duì)象建模，因而在領(lǐng)域模型中引入了一個(gè)餐桌類。</p><p>　　餐館需要記錄每張餐桌的其他信息，例如，餐桌可以容納的用餐人數(shù)。在一個(gè)對(duì)象模型中，這個(gè)信息必須作為一個(gè)類的屬性記錄，而餐桌類是存儲(chǔ)該信息的很自然的地方。圖1．7是擴(kuò)充以后包含了預(yù)定的各種特性的領(lǐng)域模型。</p><p>　　預(yù)定類和餐桌類之間的關(guān)聯(lián)的重?cái)?shù)指明一個(gè)預(yù)定只能對(duì)應(yīng)一張餐桌，排除了餐館為就座于多個(gè)餐桌的大團(tuán)體提供預(yù)

30、定的可能。</p><p>　　領(lǐng)域模型沒有涉及未預(yù)約的就餐者，未預(yù)約和預(yù)定由一些共同的屬性，就是存儲(chǔ)的基本數(shù)據(jù)和到餐桌的鏈接，但不同的是對(duì)未預(yù)約的顧客沒有顧客信息的記錄。對(duì)模型的這個(gè)細(xì)化如圖1．8所示。</p><p>　　第二章 餐館系統(tǒng)的分析</p><p><b>　　2．1 分析的目的</b></p><p>

31、　　以用例描述的形式所陳述的需求是定義系統(tǒng)外部行為非常有價(jià)值的工具，但是對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)，或如何提出一組交互的對(duì)象來(lái)支持所要求的功能并沒有給出任何指導(dǎo)。因此，把分析的任務(wù)描述為是構(gòu)造一個(gè)模型，來(lái)說(shuō)明這些交互的對(duì)象如何能夠交付用例中規(guī)定的行為。</p><p><b>　　2．2 對(duì)象設(shè)計(jì)</b></p><p>　　為了產(chǎn)生實(shí)化一個(gè)用例的交互圖，必須在一組對(duì)象之間分配

32、所需要的數(shù)據(jù)和處理，從而這些對(duì)象就可以進(jìn)行交互以支持用例規(guī)定的功能。</p><p>　　2．2．1 對(duì)象責(zé)任</p><p>　　面向?qū)ο蟪绦蛟O(shè)計(jì)的啟示是軟件對(duì)象反映的是在現(xiàn)實(shí)世界或應(yīng)用領(lǐng)域中找出對(duì)象。</p><p>　　面向?qū)ο笙到y(tǒng)中的數(shù)據(jù)不是保存在一個(gè)單獨(dú)的中央數(shù)據(jù)存儲(chǔ)中，而是分布在系統(tǒng)的所有對(duì)象中。可以用責(zé)任的術(shù)語(yǔ)來(lái)描述說(shuō)每個(gè)對(duì)象負(fù)責(zé)管理系統(tǒng)中數(shù)據(jù)的一個(gè)子

33、集。一個(gè)對(duì)象負(fù)責(zé)的數(shù)據(jù)不僅包括它的屬性值，還包括它所維護(hù)的與系統(tǒng)中其他對(duì)象的鏈接。</p><p>　　對(duì)象負(fù)有的另一類責(zé)任是支持某些處理，這些處理最終在它的類所實(shí)現(xiàn)的方法中定義。由對(duì)象進(jìn)行的處理典型地包括：在該對(duì)象可用的數(shù)據(jù)上實(shí)行某些計(jì)算，或者通過(guò)給其他對(duì)象發(fā)送消息協(xié)同進(jìn)行一個(gè)較大的操作以及用它們返回的數(shù)據(jù)做些事情。</p><p>　　對(duì)象設(shè)計(jì)的一個(gè)基本原則是，在進(jìn)行用例實(shí)化時(shí)，設(shè)計(jì)者

34、應(yīng)該定義具有功能上內(nèi)聚的責(zé)任集的對(duì)象和類。</p><p><b>　　2．3 軟件架構(gòu)</b></p><p>　　定義良好的對(duì)象應(yīng)該有一組內(nèi)聚的責(zé)任。例如，在餐館預(yù)約系統(tǒng)的情況中，可能會(huì)提出建議，顧客對(duì)象應(yīng)該負(fù)責(zé)任何與顧客有關(guān)的事宜，從在屏幕上顯示顧客信息，維護(hù)顧客的姓名和電話號(hào)碼使之可以使用，到將這些數(shù)據(jù)存儲(chǔ)到一個(gè)關(guān)系數(shù)據(jù)庫(kù)中。</p><p

35、>　　2．3．1 層次架構(gòu)</p><p>　　責(zé)任應(yīng)該交給不同的類，由一個(gè)模型類來(lái)負(fù)責(zé)維護(hù)數(shù)據(jù)，而由一個(gè)視圖類負(fù)責(zé)顯示數(shù)據(jù)。在系統(tǒng)運(yùn)行時(shí)對(duì)象之間傳遞的消息數(shù)目會(huì)增加。例如，無(wú)論何時(shí)要更新顯示，視圖類在顯示之前都必須從模型類獲取對(duì)象最近的狀態(tài)。</p><p>　　這種在模型和視圖之間進(jìn)行區(qū)分的原則可以應(yīng)用于系統(tǒng)級(jí)，導(dǎo)致識(shí)別架構(gòu)中兩個(gè)分離的層次。維護(hù)系統(tǒng)狀態(tài)和實(shí)現(xiàn)應(yīng)用業(yè)務(wù)邏輯的類置于

36、應(yīng)用層，而與用戶界面有關(guān)的類放在表示層。</p><p>　　這兩個(gè)層在圖2．1中從圖形上作了說(shuō)明。一個(gè)模型可以分為多個(gè)包，每個(gè)包又可以包含嵌套的包。</p><p>　　圖2．1還顯示了表示層和應(yīng)用層之間的依賴，說(shuō)明表示層依賴或使用應(yīng)用層中定義的類和其他模型元素?！案摺睂涌梢允褂谩暗汀睂犹峁┑奶匦?，但底層是獨(dú)立于任何高層的。</p><p><b>　　

37、2．4 用例實(shí)化</b></p><p>　　在餐館預(yù)約系統(tǒng)中，可能最簡(jiǎn)單的用例是“顯示預(yù)約”用例。</p><p>　　2．4．1 系統(tǒng)消息</p><p>　　“顯示預(yù)約”用例的實(shí)化將包含一個(gè)員工參與者的實(shí)例，因?yàn)槿魏螁T工都能夠執(zhí)行這個(gè)用例。用戶的交互基本上只是一個(gè)請(qǐng)求，即顯示指定日期的預(yù)約。這可以作為一個(gè)單獨(dú)的消息建模，相關(guān)的日期作為消息的一個(gè)參數(shù)

38、。系統(tǒng)響應(yīng)這個(gè)消息的反應(yīng)是檢索和顯示所請(qǐng)求那天的預(yù)約，從而結(jié)束用例實(shí)例。</p><p>　　2．4．2 存取預(yù)約</p><p>　　檢索相關(guān)日期的預(yù)約和更新顯示器以展現(xiàn)這些預(yù)約來(lái)替換已有預(yù)約是兩個(gè)獨(dú)立的動(dòng)作，需要某些簡(jiǎn)單的控制以確保這些動(dòng)作能夠以正確的次序發(fā)生。</p><p>　　通過(guò)向負(fù)責(zé)維護(hù)餐館全部預(yù)約的對(duì)象，發(fā)送一個(gè)請(qǐng)求給定日期的所有預(yù)約的消息來(lái)實(shí)現(xiàn)。發(fā)

39、送一個(gè)消息更新當(dāng)前的顯示。根據(jù)系統(tǒng)的架構(gòu)，這個(gè)消息應(yīng)該從預(yù)約系統(tǒng)發(fā)送到表示層中的某個(gè)類，請(qǐng)求更新顯示。</p><p>　　2．4．3 檢索預(yù)約細(xì)節(jié)</p><p>　　餐館對(duì)象識(shí)別返回的預(yù)約，邏輯上，需要獲得每個(gè)預(yù)約對(duì)象的日期，并返回與來(lái)自參與者的消息中提供的日期相匹配的預(yù)約。</p><p>　　2．4．4 細(xì)化領(lǐng)域模型</p><p>

40、　　開發(fā)“顯示預(yù)約”用例的實(shí)化的過(guò)程確定了兩個(gè)新的類和許多在類的實(shí)例之間傳遞的消息。</p><p>　　圖2．2中顯示了兩個(gè)新的關(guān)聯(lián)。第一個(gè)是從餐館類到預(yù)約類，反映了我們規(guī)定餐館類負(fù)責(zé)登記系統(tǒng)已知的所有預(yù)約細(xì)節(jié)的事實(shí)。由于預(yù)約是由另一個(gè)類的實(shí)例表示的，所以餐館能夠掌握這些預(yù)約的方法是存儲(chǔ)到每個(gè)預(yù)約的鏈接。</p><p>　　但是，還有另外一個(gè)責(zé)任，即記錄當(dāng)前顯示在屏幕上的是哪些預(yù)約的責(zé)

41、任。如果每當(dāng)它們顯示后都沒有保存，那么無(wú)論何時(shí)更新顯示時(shí)，都不得不再次從餐館對(duì)象檢索當(dāng)前的預(yù)約。</p><p>　　圖2．2采用的是另一種設(shè)計(jì)，將記住哪些預(yù)約和當(dāng)前日期相關(guān)的責(zé)任交給預(yù)約系統(tǒng)。預(yù)約系統(tǒng)和預(yù)約類之間的關(guān)聯(lián)標(biāo)明了這個(gè)信息：如同餐館對(duì)象一樣，預(yù)約系統(tǒng)通過(guò)維護(hù)一組到相關(guān)預(yù)約的鏈接來(lái)履行自己的責(zé)任。與此相關(guān)，預(yù)約系統(tǒng)類也記錄了當(dāng)前顯示的日期，作為該類的一個(gè)屬性。</p><p>&

42、lt;b>　　2．5 記錄新預(yù)約</b></p><p>　　創(chuàng)建一個(gè)新預(yù)約所需的詳細(xì)資料是由用戶界面的某些適當(dāng)?shù)脑厥占?。例如一個(gè)對(duì)話框，而用例的邏輯結(jié)構(gòu)可以由一個(gè)來(lái)自用戶的單個(gè)系統(tǒng)消息表示，該消息請(qǐng)求創(chuàng)建一個(gè)新預(yù)約，并將需要的數(shù)據(jù)作為參數(shù)傳遞。</p><p>　　2．5．1 創(chuàng)建新對(duì)象</p><p>　　在創(chuàng)建一個(gè)新預(yù)約對(duì)象之前，必須定位

43、表示預(yù)定是對(duì)之做出的餐桌和顧客對(duì)象。根據(jù)領(lǐng)域模型，每個(gè)預(yù)定對(duì)象被恰好鏈接到一個(gè)餐桌對(duì)象和一個(gè)顧客對(duì)象。因此，創(chuàng)建一個(gè)未鏈接到這些對(duì)象的預(yù)定將是實(shí)現(xiàn)錯(cuò)誤，因?yàn)橄到y(tǒng)狀態(tài)和領(lǐng)域模型中的重?cái)?shù)說(shuō)明不一致。</p><p>　　2．5．2 記錄未預(yù)約顧客的預(yù)約</p><p>　　未預(yù)約顧客的預(yù)約在一個(gè)顧客沒有提前預(yù)定而進(jìn)入餐館用餐時(shí)創(chuàng)建。它們?cè)谙到y(tǒng)中記錄的方式和預(yù)定相同，但是因?yàn)樗鼈儾缓皖櫩完P(guān)聯(lián)，所

44、以在創(chuàng)建時(shí)需要較少的信息。</p><p><b>　　2．6 取消預(yù)約</b></p><p>　　取消一個(gè)預(yù)約，用戶必須首先選擇要取消的預(yù)約，然后取消它，并在最后系統(tǒng)提示時(shí)確認(rèn)取消。</p><p>　　2．6．1 細(xì)化領(lǐng)域模型</p><p>　　這個(gè)交互中暗含著一個(gè)新責(zé)任，即記住哪個(gè)是所選預(yù)約的責(zé)任。如果這沒有在

45、某處記錄，預(yù)約系統(tǒng)對(duì)象將不知道要銷毀的是哪個(gè)預(yù)約。</p><p><b>　　2．7 更新預(yù)約</b></p><p>　　“記錄到達(dá)”用例的結(jié)構(gòu)和“取消預(yù)約”用例類似：用戶首先選擇需要的預(yù)約，接著向系統(tǒng)表明顧客已經(jīng)到達(dá)。</p><p>　　假設(shè)餐館想要記錄顧客應(yīng)約到達(dá)的時(shí)間，因而必須決定什么類來(lái)負(fù)責(zé)存儲(chǔ)這個(gè)信息。對(duì)一個(gè)未預(yù)約顧客，該信息沒

46、有意義：未預(yù)約顧客的“到達(dá)時(shí)間”實(shí)際上和開始時(shí)間相同。</p><p>　　然而，用戶很可能選擇了一個(gè)未預(yù)約的預(yù)約而不是一個(gè)預(yù)定，然后試圖記錄到達(dá)時(shí)間。如果未預(yù)約類不支持記錄“到達(dá)時(shí)間”的操作，但是發(fā)給了它這個(gè)消息，那么將出現(xiàn)一個(gè)運(yùn)行時(shí)錯(cuò)誤。為了防止這種情況，必須保證這個(gè)消息不發(fā)送給未預(yù)約對(duì)象，或者保證未預(yù)約類支持這個(gè)消息。</p><p>　　2．8 完成分析模型</p>

47、<p>　　圖2．3顯示了系統(tǒng)的類圖，包括來(lái)源于進(jìn)行用例實(shí)化的過(guò)程中的信息和決策。這個(gè)類圖也包括來(lái)自領(lǐng)域模型的信息，例如顧客、餐桌和預(yù)約類之間的關(guān)系以及不能重復(fù)預(yù)約的約束等。</p><p>　　第三章 餐館系統(tǒng)的設(shè)計(jì)</p><p>　　3．1 接收用戶數(shù)據(jù)</p><p>　　預(yù)約系統(tǒng)對(duì)象是一個(gè)應(yīng)用層的對(duì)象，所以實(shí)際上消息并不會(huì)直接發(fā)送到這個(gè)對(duì)象。必須

48、有某個(gè)表示層的對(duì)象，它的責(zé)任是接收用戶的輸入并轉(zhuǎn)發(fā)給控制對(duì)象。</p><p>　　為了執(zhí)行“顯示預(yù)約”用例，用戶首先要選擇一個(gè)適當(dāng)?shù)牟藛芜x項(xiàng)。這引起一個(gè)對(duì)話框的出現(xiàn)，在對(duì)話框中，用戶輸入需要的日期，然后單擊OK按鈕將請(qǐng)求提交給系統(tǒng)。</p><p><b>　　3．2 產(chǎn)生輸出</b></p><p>　　StaffUI類具有兩個(gè)不同的角色：

49、作為邊界類，接收來(lái)自用戶的消息轉(zhuǎn)發(fā)給控制器類；它還充當(dāng)著視圖類的角色，將應(yīng)用數(shù)據(jù)或模型呈現(xiàn)給用戶，即顯示系統(tǒng)的輸出。</p><p>　　對(duì)輸出機(jī)制的要求是，只要應(yīng)用數(shù)據(jù)的狀態(tài)改變了，屏幕上對(duì)該數(shù)據(jù)的表示就要更新，確保用戶所看到的和系統(tǒng)狀態(tài)是一致的。解決辦法：只要應(yīng)用有變化時(shí)，由應(yīng)用類來(lái)通知視圖類，那么對(duì)視圖的更新只是在需要時(shí)才發(fā)生。</p><p>　　3．3 持久數(shù)據(jù)存儲(chǔ)</p&

50、gt;<p>　　3．3．1 設(shè)計(jì)數(shù)據(jù)庫(kù)模式</p><p>　　預(yù)約需要跨會(huì)話存儲(chǔ)，這個(gè)系統(tǒng)的核心問(wèn)題是捕獲和記錄預(yù)約信息。除此之外，還有預(yù)約鏈接的餐桌和顧客對(duì)象也需要持久保存。</p><p>　　表3．1 餐館預(yù)約系統(tǒng)的數(shù)據(jù)庫(kù)模式</p><p>　　3．3．2 保存和裝入持久對(duì)象</p><p>　　為了跟蹤類的實(shí)例，同

51、時(shí)為了確保不創(chuàng)建重復(fù)的實(shí)例，需要在模型中表示出數(shù)據(jù)庫(kù)模式中引入的明確的對(duì)象標(biāo)識(shí)符。為每個(gè)持久類定義一個(gè)表示持久對(duì)象的子類，這個(gè)子類新增加一個(gè)屬性來(lái)保存明確的對(duì)象標(biāo)識(shí)符。</p><p>　　圖3．1說(shuō)明了持久性的這種實(shí)現(xiàn)的結(jié)構(gòu)，該圖顯示了對(duì)特定的Table類定義的兩個(gè)新類。</p><p>　　3．3．3 持久性和層次結(jié)構(gòu)</p><p>　　通過(guò)將應(yīng)用層分成兩個(gè)子

52、包，可以有效地使應(yīng)用層的結(jié)構(gòu)清晰化，其中一個(gè)包含基本的“領(lǐng)域”類，另一個(gè)包含支持這些類的持久性所需要的類。</p><p>　　3．4 詳細(xì)的類設(shè)計(jì)</p><p>　　系統(tǒng)類的特征的完整清單以及全部的參數(shù)和類型信息，如圖3．2所示。</p><p>　　這個(gè)類的基本責(zé)任是維護(hù)當(dāng)前預(yù)約的集合，即用戶能夠在屏幕上看到的預(yù)約，并且該類支持的操作主要是這個(gè)集合的操作，或是

53、對(duì)集合中各個(gè)預(yù)約的操作。這些預(yù)約自身不是作為這個(gè)類的一個(gè)屬性建模，而是以預(yù)約系統(tǒng)類和預(yù)約類之間的一個(gè)關(guān)聯(lián)建模。</p><p>　　3．5 動(dòng)態(tài)行為建模</p><p>　　一個(gè)完整的設(shè)計(jì)應(yīng)該指定系統(tǒng)中類的結(jié)構(gòu)和行為這兩個(gè)方面。類圖定義預(yù)約系統(tǒng)保存的數(shù)據(jù)以及數(shù)據(jù)項(xiàng)彼此相關(guān)的方式，并因此給出了系統(tǒng)靜態(tài)結(jié)構(gòu)相當(dāng)全面的描述。關(guān)于對(duì)象的行為的一些信息則由實(shí)化用例所定義并顯示在順序圖中，其中顯示了特

54、定交互所涉及的對(duì)象和消息。</p><p>　　3．5．1 消息的順序</p><p>　　消息發(fā)送給對(duì)象的順序?qū)⒁蕾囉趯?duì)象的環(huán)境。例如，發(fā)送給預(yù)約系統(tǒng)的消息最終將依賴系統(tǒng)用戶所采取的行為，而不是依賴系統(tǒng)中執(zhí)行的任何處理。</p><p>　　3．5．2 與歷史有關(guān)的行為</p><p>　　某些消息具有在不同時(shí)間從一個(gè)對(duì)象引起不同響應(yīng)的特征

55、。例如，在記錄一個(gè)到達(dá)餐館時(shí)，這個(gè)預(yù)約的到達(dá)時(shí)間應(yīng)該相應(yīng)地設(shè)置。然而，如果隨后的消息再次發(fā)送給相同的對(duì)象，將不會(huì)改變對(duì)象的狀態(tài)，因?yàn)橐粋€(gè)預(yù)定到達(dá)多次沒有意義。</p><p>　　讓對(duì)象負(fù)責(zé)檢查在它的當(dāng)前狀態(tài)沒有意義的消息。由于一個(gè)消息的效果可以依賴于先前已經(jīng)發(fā)送給它的消息，這意味著對(duì)象必須以某種方式知道它們的歷史，或者知道它們已經(jīng)接收的消息。</p><p>　　3．5．3 指定行為&l

56、t;/p><p>　　對(duì)象行為有兩個(gè)方面在交互圖中沒有捕獲，但是需要作為系統(tǒng)設(shè)計(jì)的一部分明確說(shuō)明。</p><p>　　對(duì)象預(yù)期接收什么消息序列；</p><p>　　對(duì)象如何響應(yīng)消息，尤其是這個(gè)響應(yīng)如何依賴于對(duì)象的歷史，即它已經(jīng)接收的消息。</p><p>　　3．6 預(yù)約系統(tǒng)的狀態(tài)圖</p><p>　　預(yù)約系統(tǒng)類顯示

57、的最重要的依賴狀態(tài)行為與預(yù)約的選擇有關(guān)。某些消息，如recordArrival，只能在已經(jīng)選擇了一個(gè)預(yù)約的條件下被切合實(shí)際地處理?；緞?dòng)態(tài)在圖3．3的狀態(tài)圖中定義。</p><p>　　在任一給定的時(shí)間，對(duì)象總是處于它可能的狀態(tài)之一。當(dāng)它接收到一個(gè)消息對(duì)應(yīng)于從它當(dāng)前狀態(tài)出發(fā)的轉(zhuǎn)換上的事件時(shí)，該轉(zhuǎn)移被激發(fā)，而對(duì)象進(jìn)入轉(zhuǎn)換另一端的狀態(tài)。例如，假定當(dāng)前沒有選擇的預(yù)約，預(yù)約系統(tǒng)將處于圖3．3左部所示的NotSelecte

58、d狀態(tài)。如果現(xiàn)在發(fā)生“顧客到達(dá)”的交互，預(yù)約系統(tǒng)將會(huì)先收到一個(gè)selectBooking消息，這將引起標(biāo)記該消息名字的轉(zhuǎn)換被激發(fā)，而預(yù)約系統(tǒng)對(duì)象將遷移到Selected被選中狀態(tài)。然后，接收到recordArrival消息，標(biāo)記為recordArrival的轉(zhuǎn)換激發(fā)。但是，這使預(yù)約系統(tǒng)還處于接收消息之前的狀態(tài)。只有在預(yù)約處于被選中狀態(tài)時(shí)才有意義的其他消息是transfer和cancel。transfer和recordArrival的行為

59、方式相同，但是cancel的結(jié)果略有不同。一旦取消了一個(gè)預(yù)約，它將從顯示中消除并被刪除，所以不會(huì)再存在一個(gè)選中的預(yù)約。因此，在狀態(tài)圖中，標(biāo)記著cancel的轉(zhuǎn)換必須將系統(tǒng)移回到NotSelected狀態(tài)，如圖3．4所示。</p><p>　　3．6．1 非確定性</p><p>　　圖3．5說(shuō)明了收到selectBooking消息的所有可能結(jié)果。假定如果在屏幕上一個(gè)空位置單擊鼠標(biāo)，任何已選

60、擇的預(yù)約仍處于選定。</p><p>　　3．6．2 監(jiān)護(hù)條件</p><p>　　在被建模的系統(tǒng)中真正存在非確定性的情況下，像圖3．5那樣的狀態(tài)圖是完全適合的。在預(yù)約系統(tǒng)的情況中，完全依賴于和selectBooking消息一起傳遞的參數(shù)。</p><p>　　通過(guò)為相關(guān)轉(zhuǎn)換增加監(jiān)護(hù)條件，在狀態(tài)圖中可以表明這些事實(shí)。圖3．6說(shuō)明了如何指定監(jiān)護(hù)條件以解決圖3．5中的不

61、確定性。</p><p>　　在圖3．6中，任何時(shí)候，都只有一個(gè)監(jiān)護(hù)條件可以為真，消除了圖3．5中的非確定性。</p><p><b>　　3．6．3 動(dòng)作</b></p><p>　　圖3．7所示的是帶有動(dòng)作的狀態(tài)圖，以強(qiáng)調(diào)新預(yù)約將被選擇的情況。</p><p>　　3．7 預(yù)定的狀態(tài)圖</p><

62、p>　　預(yù)定類提供了用狀態(tài)圖概括一個(gè)類的對(duì)象的行為的另一個(gè)示例。預(yù)定的確顯示出了依賴于狀態(tài)的行為：一旦已經(jīng)記錄了到來(lái)者，就不可能取消預(yù)約，或者再次記錄到達(dá)?？偨Y(jié)這個(gè)行為的狀態(tài)圖如圖3．8所示。</p><p>　　這個(gè)圖中顯示了兩個(gè)狀態(tài)，Booked狀態(tài)對(duì)應(yīng)于已經(jīng)進(jìn)行了預(yù)定，但是顧客還沒有到達(dá)餐館的時(shí)候，而Seated狀態(tài)為顧客到達(dá)并且系統(tǒng)記錄了到達(dá)的時(shí)間。</p><p>　　在任

63、何時(shí)間改變分配給一個(gè)預(yù)定的餐桌都是可能的，所以，每個(gè)狀態(tài)上都出現(xiàn)有一個(gè)setTable轉(zhuǎn)換。</p><p>　　第四章 餐館系統(tǒng)的實(shí)現(xiàn)</p><p><b>　　4．1 實(shí)現(xiàn)圖</b></p><p><b>　　4．1．1 構(gòu)件</b></p><p>　　構(gòu)件是表示系統(tǒng)部件的物理實(shí)體。圖4．

64、1是一個(gè)簡(jiǎn)單的類的構(gòu)件。</p><p><b>　　4．1．2 構(gòu)件圖</b></p><p>　　組成系統(tǒng)的源文件可以顯示在構(gòu)件圖上。構(gòu)件圖顯示了依賴性鏈接的構(gòu)件，這種依賴性典型地表示構(gòu)件之間的編譯依賴。在兩個(gè)源文件之間，如果要編譯一個(gè)，另一個(gè)必須是可用的，那么二者之間存在編譯依賴。</p><p><b>　　4．1．3 部署圖

65、</b></p><p>　　部署圖表明在部署系統(tǒng)時(shí)，系統(tǒng)中的構(gòu)件如何映射到處理器。餐館預(yù)約系統(tǒng)最初的意圖是作為在獨(dú)立的PC上運(yùn)行的單用戶應(yīng)用來(lái)部署的，如圖4．2所示。</p><p><b>　　4．2 操作的實(shí)現(xiàn)</b></p><p>　　餐館預(yù)約系統(tǒng)的日常界面如圖4．3所示，以圖形界面顯示當(dāng)前餐館的座位情況，除了等待顧客用餐

66、的空桌，以及已經(jīng)有顧客就餐的滿桌外，還預(yù)設(shè)了“自用”、“維修”、“將到”、“將離”幾種情況，更易適應(yīng)各種突發(fā)狀況。當(dāng)遇到需要進(jìn)行預(yù)約的顧客時(shí)，通過(guò)“業(yè)務(wù)管理”菜單下的子菜單進(jìn)入“預(yù)定管理”界面，如圖4．4所示。</p><p>　　圖4．3 餐館預(yù)約系統(tǒng)主界面</p><p>　　“預(yù)定管理”界面實(shí)行對(duì)數(shù)據(jù)庫(kù)中數(shù)據(jù)的查詢、添加、修改、刪除的操作。滿足餐館日常營(yíng)業(yè)的需求。</p>

67、<p>　　圖4．4 “預(yù)定管理”界面</p><p><b>　　參考文獻(xiàn)：</b></p><p>　　[1] 普里斯特 著.龔曉慶 等譯. 面向?qū)ο笤O(shè)計(jì)UML實(shí)踐（第2版）. 北京：清華大學(xué)出版社.2005.</p><p>　　[2] Mike O’ Docherty 著.俞志翔 譯. 面向?qū)ο蠓治雠c設(shè)計(jì)（UML 2．0版

68、）. 北京：清華大學(xué)出版社.2006.</p><p>　　[3] Jorgensen．P．C 著.韓柯 杜旭濤 譯. 軟件測(cè)試（原書第2版）. 北京：機(jī)械工業(yè)出版社.2003.</p><p><b>　　小組成員及分工：</b></p><p>　　徐昊騫 279081203106 </p><p>