基于uml的餐館預約系統(tǒng)的設計與實現(xiàn)

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

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

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

4、lt;/p><p>　　用例視圖應該是客戶、最終用戶、領域專家、測試人員和任何其他涉及系統(tǒng)的人員，不需要詳細了解系統(tǒng)結構和實現(xiàn)就容易理解的。用例視圖不描述軟件系統(tǒng)的組織或結構，它的作用是給設計者施加約束，設計者必須設計出一個能夠提供用例視圖中指定的功能的結構。</p><p><b>　　1．2．1 用例</b></p><p>　　通過考慮在系統(tǒng)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22、</p><p>　　1．4．3 用例擴展</p><p>　　“記錄到達”用例的可選事件路徑規(guī)定，如果系統(tǒng)沒有記錄一個顧客的預約，侍者領班將通過創(chuàng)建一個未預約登記來表示他們在餐館用餐的事實。但是，將記錄未預約登記表示為單獨一個用例可能更好一些，因為未預約登記將會為那些從不提前進行預約的顧客創(chuàng)建。</p><p>　　“記錄未預約顧客”用例的基本事件路徑將會被某個沒

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

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

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

26、</p><p>　　“調換餐桌”用例的基本事件路徑也可以獨立于用戶界面的細節(jié)進行定義如下。</p><p>　　調換餐桌：基本事件路徑</p><p>　　侍者領班選擇需要的預約；</p><p>　　侍者領班改變該預約的餐桌分配；</p><p>　　系統(tǒng)記錄改變并更新顯示。</p><p>

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

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

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

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

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

32、所需要的數(shù)據(jù)和處理，從而這些對象就可以進行交互以支持用例規(guī)定的功能。</p><p>　　2．2．1 對象責任</p><p>　　面向對象程序設計的啟示是軟件對象反映的是在現(xiàn)實世界或應用領域中找出對象。</p><p>　　面向對象系統(tǒng)中的數(shù)據(jù)不是保存在一個單獨的中央數(shù)據(jù)存儲中，而是分布在系統(tǒng)的所有對象中。可以用責任的術語來描述說每個對象負責管理系統(tǒng)中數(shù)據(jù)的一個子

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

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

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

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

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

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

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

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

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

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

43、表示預定是對之做出的餐桌和顧客對象。根據(jù)領域模型，每個預定對象被恰好鏈接到一個餐桌對象和一個顧客對象。因此，創(chuàng)建一個未鏈接到這些對象的預定將是實現(xiàn)錯誤，因為系統(tǒng)狀態(tài)和領域模型中的重數(shù)說明不一致。</p><p>　　2．5．2 記錄未預約顧客的預約</p><p>　　未預約顧客的預約在一個顧客沒有提前預定而進入餐館用餐時創(chuàng)建。它們在系統(tǒng)中記錄的方式和預定相同，但是因為它們不和顧客關聯(lián)，所

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

67、<p>　　圖4．4 “預定管理”界面</p><p><b>　　參考文獻：</b></p><p>　　[1] 普里斯特 著.龔曉慶 等譯. 面向對象設計UML實踐（第2版）. 北京：清華大學出版社.2005.</p><p>　　[2] Mike O’ Docherty 著.俞志翔 譯. 面向對象分析與設計（UML 2．0版

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